Big Endian o Little Endian (porque uno u otro)

[Raster]

Hola:

Lo mío es una sospecha, o suposición, no tengo pruebas reales. Pero si lo pensáis, si queréis sumar un número de 16 bits al que apunta un puntero, el little-endian es el sistema lógico, pues sumas el primer byte y si hay desbordamiento se te pone el acarreo a 1, incrementas el puntero, sumas el segundo byte más acarreo, y listo. Y si incrementas una vez más el puntero, ya pasa a apuntarte al siguiente número . En cambio, en big-endian tendrías primero que sumar 1 al puntero para apuntar a la parte baja, sumarlo, decrementarlo para que apunte a la parte alta, sumar de nuevo... y encima el puntero te apunta ahora de nuevo al principio del número, con lo que tendrías que sumar dos (o más si son números de 32 bits) para pasar al siguiente.

En cambio, si queréis comparar dos números de 16 bits para ver cual es mayor, os interesa big-endian, porque primero comparáis el primer byte. Si uno es más grande que el otro, ya tenéis el resultado, pero si son iguales, tenéis que pasar al siguiente y comparar de nuevo, y así hasta que lleguéis al final del número.

Y la cuestión es que el Intel 8080 (y, por extensión, el Z80) tiene instrucciones aritméticas de 16 bits, que como ya he dicho se implementan mejor en little-endian, mientras que el Motorola 6800 tiene una instrucción para comparar números de 16 bits, pero no aritméticas. Y creo que esto es precisamente lo que explica por qué cada fabricante se decantó por un formato u otro: por el tipo de operaciones de 16 bits que decidió soportar.

[Bubu]

Hola, Raster, no entiendo muy bien la ventaja que comentas del little endian para las sumas de 16 bits, ya que para una CPU es igual de costoso incrementar una posición que decrementarla. Verás:

En little endian tienes a, A, y si quieres sumas ese número de 16 bits a HL, pues la CPU captura "a", lo carga a través del bus de datos en la parte baja, incrementa 1 el registro PC, captura "A", lo carga a través del bus de datos en la parte alta, y hace la operación que tenga que hacer. Si hay acarreo y quieres seguir sumando, pues repites esto con las siguientes posiciones, en las que tendrías b, B

En big endian tienes A, a, y simplemente cargas el primero en la parte alta, y el segundo en la baja, pero la operación y el coste es el mismo.

[Raster]

No, no es así exactamente. Piensa que lo normal es que si un entero que ocupa varios bytes está apuntado por un puntero, el puntero suele apuntar a la dirección más baja, que en little-endian sería el byte bajo pero big-endian sería el byte alto. Imagínate también que haces un malloc en C de un bloque con varios enteros: el puntero que te devuelve apunta a la parte baja, no a la alta. Y así con todo. Decrementar un puntero no es "lo habitual".

Otro ejemplo: imagínate que te dan una lista de enteros de 16 bits cada uno en un bloque de memoria, y te dicen que los sumes hasta que encuentres un valor que sea cero. En little-endian pones el puntero al principio y vas incrementando para arriba. En big-endian tienes que leer "en zig-zag". Y si me dices que lees 16 bits de una tacada, subo la apuesta y cambio a una lista de enteros de 32 bits, o de 64: un tamaño para el que no tengas una operación nativa y que te obligue a enlazar varias sumas a través del acarreo. En ese caso, sumar "de corrido" siempre será más directo con little-endian que con big-endian.

No se si he conseguido explicarme.

[explorer]

Procesadores como el 6809 o el 68000, que son big endian, cuentan con modos de direccionamiento en que pueden incrementar o decrementar los registros índice después de realizar una operación para apuntar al siguiente dato en memoria.

Por regla general, a un procesador le da igual si cuenta con instrucciones suficientes para operar con los punteros.

Incluso hay arquitecturas, como las de ARM o Power-PC que pueden funcionar con las dos.

Y luego está este tema fuera de los procesadores. La escritura de nuestros números es "big-endian" así como en la mayor parte del intercambio de información binaria en los protocolos de red.

Endianness

[Raster]

Claro, pero esos dos llegaron bastante después del 6800, y cabe suponer que la inercia hizo que siguiesen utilizando big-endian.

[Namek]

"A big-endian system stores the most significant byte of a word at the smallest memory address and the least significant byte at the largest."

Lo estoy entendiendo mal o los términos deberían llamarse "BIG STARTIAN" y "LITTLE STARTIAN"???

[Skuall]

En el enlace que ha puesto explorer lo explican muy bien en la parte de Etymology.

Y aquí el documento original:

https://www.rfc-editor.org/ien/ien137.txt

[Bubu]

No, no es así exactamente. Piensa que lo normal es que si un entero que ocupa varios bytes está apuntado por un puntero, el puntero suele apuntar a la dirección más baja, que en little-endian sería el byte bajo pero big-endian sería el byte alto.

Pero esa manera de actuar es del software, es decir, depende del lenguaje de pogramación. Para una CPU, que recibe impulsos elestrónicos (a través del lenguaje máquina), si obtienes un registro de 16 bits en una tesnología little-endian, pos la CPU apunta al byte de menos peso, lo pilla, lo carga en L, incrementa la posición y apunta al byte de más peso, lo pilla, y lo carga en H.
Si la CPU fuera big-endian, pos la CPU apunta al primer byte, que es el de más peso, lo pilla, lo carga en H, incrementa la posición y apunta al byte de menos peso, lo pilla, y lo carga en L.

Al final tienes lo mismo, y al mismo coste.

[Raster]

Pero esa manera de actuar es del software, es decir, depende del lenguaje de pogramación.

Pero es que esa es la cuestión: en los años 70 se intentaba que el código máquina simplificase la programación, por eso se añadían instrucciones tan complejas como LDIR o CPIR en el Z80. Hoy en día, habiendo memoria y reloj a espuertas te puede dar igual, pero hace cuarenta años, no.

[Bubu]

Bueno, AJjJa, yo es que pogramo direstamente en ensamblador, y por tanto no me afesta si es little o big endian.