Por cierto, conozco un argumento que históricamente favorecía el formato little-endian: en una serie de CPU, especialmente en el 6502, el código podría ejecutarse más rápido usando el formato little-endian que lo que hubiera sido posible con big-endian. Considere, por ejemplo, una instrucción:
$1234: LDA ($8A),Y ; Load byte from Y register plus the value stored in $008B-$008A
Assume $008B-$008A hold $5432, and Y holds $10
La secuencia de ejecución es:
$1234 read $B1 - Fetch opcode
$1235 read $8A - Fetch operand
$008A read $32 - Fetch LSB of target while adding $01 to $8A
$008B read $54 - Fetch MSB of target while adding $32 to $10
$5442 read $XX - Fetch byte from target
El MSB y el LSB de cualquier dirección que se lea o escriba deben basarse en un cálculo realizado en el último ciclo con valores ya en la CPU, o bien debe ser el último valor verbal extraído. El tercer ciclo puede leer el primer byte de la dirección de destino (es decir, $ 8A) sin demora; Si el procesador quisiera leer primero el segundo byte, tendría que perder un ciclo calculando la dirección. El cuarto ciclo puede calcular el LSB de la dirección de destino al obtener el MSB; si no se retira el LSB, el LSB (calculado) y el MSB (recuperado de la memoria) estarán listos simultáneamente. Si el 6502 fuera big-endian, sería necesario desperdiciar un ciclo en cada acceso indexado (en lugar de perder solo un ciclo cuando la indexación cruza un límite de 256 bytes).
No tengo conocimiento de ninguna ventaja de procesamiento para el formato big-endian más allá del hecho de que fue elegido arbitrariamente como el orden de bytes de red "estándar".