Endianess: Big-Endian y Little-Endian

13May08

Al momento de escribir o leer un dato en un archivo desde nuestra aplicación nos encontramos con un problema: en que orden debemos almacenar los mismos?

El problema se hace más evidente al almacenar elementos de más de un byte, como números enteros, flotantes, etc. Por ejemplo, si queremos almacenar el valor hexadecimal 0x1A2B3C4D podemos rápidamente diferenciar dos órdenes:

  • Del byte más al menos significativo (0x1A, 0x2C, 0x3C, 0x4D)
  • Del byte menos al más significativo (0x4D, 0x3C, 0x2C, 0x1A)

A los formatos en que se almacenarán los datos se los conoce como Endianess. Siendo el formato del primer ejemplo (de + a – significativo) conocido como Big-Endian, mientras que al formato del segundo ejemplo (de – a + significativo) se lo conoce como Little-Endian.

Veamos más en detalle cada uno de estos:

Big-Endian

Este formato fue promovido entre otros por Motorola, y quiere decir “Del más grande al final”.

En el se comienza almacenando del byte más al menos significativo, exactamente igual que como solemos representar los números (por lo menos por estos lados del mundo), siendo el primer byte el que tiene más peso en la secuencia.

Ejemplo 1: Array de datos de 1 Byte cada uno

Si deseamos almacenar:
0x47, 0xEF, 0x15, 0x2A, 0x89, 0x37, 0x84, 0x33

Obtendríamos:

Array de datos de 1 Byte cada uno

Ejemplo 2: Array de datos de 2 Bytes cada uno

Si deseamos almacenar:
0x47EF, 0x152A, 0x8937, 0x8433

Obtendríamos:

Array de datos de 2 Bytes cada uno

Ejemplo 3: Array de datos de 4 Bytes cada uno

Si deseamos almacenar:
0x47EF152A, 0x89378433

Obtendríamos:

Array de datos de 4 Bytes cada uno

Little-Endian

Este formato fue promovido entre otros por Intel, y quiere decir “Desde el pequeño al final”.

En el se comienza almacenando del byte menos al más significativo, siendo el ultimo byte el que tiene más peso en la secuencia.

Ejemplo 4: Array de datos de 1 Byte cada uno

Si deseamos almacenar:
0x47, 0xEF, 0x15, 0x2A, 0x89, 0x37, 0x84, 0x33

Obtendríamos:

Array de datos de 1 Byte cada uno

Como podemos observar no se nota la diferencia con el big-endian en este caso.

Ejemplo 5: Array de datos de 2 Bytes cada uno

Si deseamos almacenar:
0x47EF, 0x152A, 0x8937, 0x8433

Obtendríamos:

Array de datos de 2 Bytes cada uno

Aquí se puede apreciar como se invierte el orden de los bytes, en comparación con el mismo dato en big-endian, en cada uno de los datos de 2 bytes.

Ejemplo 6: Array de datos de 4 Bytes cada uno

Si deseamos almacenar:
0x47EF152A, 0x89378433

Obtendríamos:

Array de datos de 4 Bytes cada uno

Aquí se puede apreciar como se invierte el orden de los bytes, en comparación con el mismo dato en big-endian, en cada uno de los datos de 4 bytes.

Hasta la proxima.

Más Info



9 Responses to “Endianess: Big-Endian y Little-Endian”

  1. 1 David

    Muy buena explicación. Me ha quedado muy claro tras tu explicación.

    Un saludo

  2. Muy buen resumen del endianess, Luis🙂 . Estoy ahora con ensamblador y estaba buscando algunos de esos conceptillos que a veces se nos olvidan. Gracias por la info!😉

    @Muammar, Yo diría que una máquina middle-endian, que admite los dos formatos, sería útil para casos muy concretos. Si programas en lenguajes de alto nivel, a menos que toquetees cosas de la máquina a nivel de memoria, poco debería importarte el endianess. Yo casi preferiría una máquina con un solo formato de endianess, porque a la hora de trabajar a bajo nivel, cambiar de formato requeriria cambiar la implementacion de mucho codigo. Digo bajo nivel como ensamblador y similar, porque en otro caso, GCC, el JVM, o lo que sea que te toque usar, se encargará por debajo de vérselas con la máquina.

    Sí es verdad que en C puedes tener algún problemila cuando trabajas con memoria. IBM escribió un artículo de cómo escribir código C independiente del endianness bastante bueno: http://www.ibm.com/developerworks/aix/library/au-endianc/index.html?ca=drs-

    • Hola @Antonio. Gracias por tu respuesta, me has aclarado un par de dudas. Yo no estaba muy seguro (soy licenciado en química :)) de las ventajas de las arquitecturas Bi-endian. Lo que dices tiene mucho sentido, y lógica. Estoy bastante de acuerdo.

      Saludos

  3. Qué podrías decir al respecto de las arquitecturas que son Bi-endian, como el caso de ARM, MIPS e IA64 entre otros. ¿Hay alguna ventaja en este tipo de arquitecturas? yo creo que sí, pero no se si habrán pruebas o publicaciones que digan lo contrario.

  4. Realmente el tema de que formato “es el mejor” o “es el correcto” es muy largo, con defensores y detractores en cada lado.

    El principal argumento a favor de los defensores de little endian es la facilidad de escribir operaciones matemáticas, ya que los bytes y las posiciones quedan con un mismo offset, de forma que el byte-0 está en la posición-0, el byte-1 en la posición-1, etc., por ejemplo con el número 0×47EF152A:

    posición: byte
    0: 0x2A
    1: 0x15
    2: 0xEF
    3: 0x47

    Mientras que los defensores de big endian argumentan que al leer el byte más significativo primero pueden saber el signo y la magnitud del valor sin tener que leer el resto de la secuencia de bytes.

    Es un tema interesante, acá hay una pequeña discución del tema: http://www.cs.umass.edu/~Verts/cs32/endian.html

  5. 6 Hugo

    ¡Hola! ¿Es una simple convención o tiene algún sentido que Intel haya elegido un formato inverso al que, al menos creo, funciona nuestra lógica?

  6. 7 edith

    what???
    help!!!


  1. 1 Anónimo
  2. 2 Interpretando Big/Little Endian desde Java « Le Funes

A %d blogueros les gusta esto: