Big Endian o Little Endian (porque uno u otro)

[mentalthink]

Quería haceros está pregunta, porque no he encontrado en un par de búsquedas la solución.
Lo que hacen lo tengo más o menos claro, que el Byte más significativo es el de la izquierda o el de la derecha, según escojamos, o que las máquinas pueden usar los 2 tipos cambiando por hardware o soft la configuración.

Pero el asunto es:
Para que quiero usar uno u otro, que gano yo teniendo 1111 0000 o 0000 1111, supongo que la respuesta debe de ser por temás de velocidad de acceso o mejor dicho de interpretar los datos con más velocidad pero... que no lo veo claro... Si algún apañao me lo explica se lo agradecería.

[BlackHole]

El término se refiere al orden de los bytes almacenados en la memoria o en una transmisión de datos, a la hora de calcular su peso relativo, y no al orden de los bits como tú has escrito en tu ejemplo. Por lo tanto, las sucesiones 11110000 y 00001111 equivalen a 2 números diferentes (el 240 y el 15) en ambos sistemas. Solo tiene sentido en números mayores de 255 que necesiten más de 1 byte para ser representados, pero luego cada byte sigue teniendo el bit más significativo a la izquierda. Esto hace que en los equipos Little Endian las operaciones de rotación de bits sean más peliagudas e innecesariamente complicadas.

Por lo general el diseño de un microprocesador fija un orden inamovible desde su concepción. Motorola es Big Endian y curiosamente Intel es Little Endian, y contra toda lógica es el que se impuso. Los procesadores que permiten trabajar en ambos modos son pocos, normalmente pertenecientes a las familias ARM y MIPS, aunque luego no se puede cambiar de uno a otro modo aleatoriamente, suele ir fijado por el hardware de la placa o se define en el arranque del código del firmware.

Curiosamente, debido a que el primitivo diseño de las unidades aritmético-lógicas (ALU) de los procesadores de 8 bits eran Little Endian (tanto el Intel 8080, como su "clon" el Zilog Z80, como después por costumbre el MOS 6502) puesto que les parecía "logico" que los bits que desbordaban una operación de 8 bits se almacenasen en una posición posterior en la memoria, y por la necesidad del primer micro de 16 bits Intel 8086 de ser compatible hacia atrás, venimos arrastrando procesadores Little Endian desde los diseños iniciales de procesadores en 1974, pero luego se ha visto que no es la forma más óptima de trabajar.

Quizás si desde el primer momento, hubiesen definido que el orden de los bits más significativos en los números binarios, estuviesen a la derecha en vez de la izquierda, todo hubiese sido más cómodo y el mundo se habría acostumbrado a un solo sistema de representación, pero a estas alturas ya nunca lo sabremos.

Te aconsejo leer el artículo de Wikipedia en inglés sobre el tema, ya que su versión en español es bastante escasa en el tema Bi-endian.

[alt]

Respuesta académicamente impecable: explicación técnica, desarrollo histórico, referencia bibliográfica para ampliar conocimiento. Blackhole debería estar dando clase en la universidad.

[explorer]

Esto hace que en los equipos Little Endian las operaciones de rotación de bits sean más peliagudas e innecesariamente complicadas.

¿Algún ejemplo? Se supone que el coste de desplazamiento en ambos sentidos debería ser igual. Y el pasar el bit que sale al siguiente byte consiste en sumar o restar uno a la dirección del puntero y rotar en el mismo sentido que hacíamos en el primer byte. ¿O se me escapa algo?

puesto que les parecía "lógico" que los bits que desbordaban una operación de 8 bits se almacenasen en una posición posterior en la memoria,

Bueno... si hay un desborde, solo tengo que incrementar el puntero. En Big Endian lo decrementaría, ¿no?

pero luego se ha visto que no es la forma más óptima de trabajar.

¿Ejemplo?

Quizás si desde el primer momento, hubiesen definido que el orden de los bits más significativos en los números binarios, estuviesen a la derecha en vez de la izquierda, todo hubiese sido más cómodo y el mundo se habría acostumbrado a un solo sistema de representación, pero a estas alturas ya nunca lo sabremos.

Eso se llama el Bit endianness, pero actualmente se refiere a la transmisión serie de bits.

P.D.: Yo también prefiero el Big Endian. Herencia de haber pasado del 6502 al 68000

[BlackHole]

Aunque alt por alguna extraña razón me alabe el comentario, hay veces que lo que relato sale de las tripas y del corazón en vez de la cabeza. Por lo tanto como siempre va a haber gente que vaya a cazar inexactitudes, y ya que este foro se ha convertido en una Wikipedia donde no puedes expresar opiniones y todo tiene que ser exacto en tus declaraciones, va a ser mi última intervención en él.

Es cierto que al procesador le cuesta lo mismo rotar para un lado que rotar para el otro, le cuesta lo mismo incrementar que decrementar. Cuando dije mis desafortunadas palabras es porque tenía en la mente desagradables experiencias pasadas a la hora de manipular números de 16 o 32 bits en procesadores de 8 bits, algo que hoy en día nadie va a hacer; o al intentar cambiar de Endian como cuando manipulas los campos de un paquete TCPIP desde un procesador x86 moderno, donde tienes que rotar 3 veces y hacer OR otras 3 para darle la vuelta a un valor de 32 bits. Era eso lo que tenía en mente, me equivoqué al escribirlo y alguien que sí es profesor de universidad, se ha dado cuenta de mi error.

En fin... eso es todo lo que tenía que decir.

[Bubu]

Yo estoy acostumbrado a pogramar con Little Endian, porque el Spectrum es el que utiliza (por el Z80), y como parece ser cuestión de antojo, es decir, no hay nada mejón ni peor, pos por lo menos me sirve para seguir la siguiente regla : en la memoria más baja almaceno el byte más bajo. En el Big Endian sería alrevés.

Además, estoy pensando ahora una cosa, imagínate la memoria RAM distribuida de la siguiente manera:

Dirección 0 ,bit 0
Dirección 0, bit 1
Dirección 0, bit 2
...
Dirección 0, bit 7
Dirección 1, bit 0
Dirección 1, bit 1
...
Dirección 1, bit 7
Dirección 2, bit 0
...

Entonces el Little Endian es la forma más lógica de guardar un número de 16 bits: en orden de menor peso a mayor peso. Lo que pasa es los humanos cuando leemos un número siempre leemos primero la parte más pesada y luego la más ligera (p.ej. el número 135, escribimos primero el 1 que es la parte más pesada), pero viendo ese ejemplo de almacenamiento parece lógico que el ordeñador empiece a leer primero la parte más ligera y aluego la más pesada.

Pero a los humanos con las fechas nos pasa alrevés: hoy es 11/05/2019. Primero leemos la parte más ligera (11), después el mes, y por último la parte más pesada, el año. Aquí usaríamos el Little Endian para las fechas. El caso es que a mí me gustaría que todo fuera Big Endian, y por eso siempre escribo las fechas así: 20190511.

En fins, parece cuestión de estética elegir uno u otro sistema.

[alt]

Aunque alt por alguna extraña razón me alabe el comentario, hay veces que lo que relato sale de las tripas y del corazón en vez de la cabeza.

Tío, relativiza. Sigo diciendo que tu respuesta es muy válida como mínimo desde un punto de vista formal académico, porque aunque haya una metedura de pata, encaja perfectamente con el canon de cómo debe ser una exposición. Si contiene errores, ofreces la posibilidad de profundizar en el tema con el enlace y aceptar o falsar lo que expones.

Por otro lado, todos metemos algún gambazo, sobre todo si escribimos en un foro a vuela pluma sobre un tema que conocemos y del que estamos lanzando aseveraciones que no fundamentamos de forma exhaustiva (cosa que no se puede hacer en un texto formal). En este contexto, no creo que el conjunto de tu exposición quede invalidado por ello, ni que sea menos valioso.

[explorer]

Aquí venimos a discutir y aprender todos. Yo también meto la pata, y muchas veces. Y más cuanto más viejo me hago (la cabeza ya no es la de los veinte años).

Mis preguntas estaban hechas desde el punto de vista de la curiosidad, sin doble intención.

Por si queda alguna duda: cada vez que tengo que ponerme con un micro a programarlo en ensamblador, hecho pestes del Endianness.

[zup]

Es cierto que al procesador le cuesta lo mismo rotar para un lado que rotar para el otro, le cuesta lo mismo incrementar que decrementar. Cuando dije mis desafortunadas palabras es porque tenía en la mente desagradables experiencias pasadas a la hora de manipular números de 16 o 32 bits en procesadores de 8 bits, algo que hoy en día nadie va a hacer; o al intentar cambiar de Endian como cuando manipulas los campos de un paquete TCPIP desde un procesador x86 moderno, donde tienes que rotar 3 veces y hacer OR otras 3 para darle la vuelta a un valor de 32 bits. Era eso lo que tenía en mente, me equivoqué al escribirlo y alguien que sí es profesor de universidad, se ha dado cuenta de mi error..

Perdón por la burrada, pero...

Yo creía que el endian era un criterio de diseño, que se decidía antes de empezar a diseñar el microprocesador y luego se apechugaba con ello. Quizás a nivel electrónico haya ventajas en utilizar uno u otro (espacio usado, número de transistores, velocidad), pero eso es todo. Obviamente, el sistema en sí tiene que "heredar" el endian de la CPU si no quieres volverte loco.

En el caso que mencionas (aquí puede ir otra burrada), TCP/IP trata de un método de comunicación entre ordenadores que no tienen que tener el mismo endian. No creo que el hecho de dar la vuelta al valor de 32 bits tenga que ver con que x86 tenga el endian "malo", sino que las personas que diseñaron el protocolo lo diseñaron en otra época y estaban pensando en el endian contrario al que se ha impuesto. Si lo hicieran hoy en día, supongo que tirarían hacia el little endian (porque estarán más acostumbrados a él, no por ventajas inherentes).

[mentalthink]

Gracias a Black Hole por la extensa y clarificadora explicación. y a los demás por aportar más soporte. Gracias.