¿Ha ganado Little Endian?

34

Cuando enseñé recientemente sobre la batalla Big vs. Little Endian, un estudiante preguntó si se había resuelto, y me di cuenta de que no lo sabía. Al mirar el artículo de Wikipedia , parece que los pares de arquitectura / SO actuales más populares usan Little Endian, pero ese Protocolo de Internet especifica Big Endian para transferir valores numéricos en encabezados de paquetes. ¿Sería un buen resumen del estado actual? ¿Las tarjetas de red o CPU actuales proporcionan soporte de hardware para cambiar el orden de bytes?

— Ellen Spertus
fuente

25

Yo diría que no se ganó tanto como dejó de importar. El BRAZO que constituye básicamente todo el mercado móvil es bi-endian (¡oh, la herejía!). En el sentido de que x86 básicamente "ganó" el mercado de las computadoras de escritorio, supongo que se podría decir que Little Endian ganó, pero creo que dada la profundidad general del código (superficial) y la abstracción (lotes) de muchas de las aplicaciones actuales, es mucho menos un problema que solía ser. No recuerdo el endianness realmente en mi clase de Arquitectura de Computadores.

Sospecho que muchos desarrolladores ni siquiera son conscientes del endianness o por qué es importante. Porque para la gran mayoría (y me refiero a la gran mayoría) es completamente irrelevante para su entorno de trabajo diario. Esto fue diferente hace 30 años cuando todos codificaban mucho más cerca del metal en lugar de manipular archivos de texto en una pantalla de manera elegante y dramática.

Mi sospecha general es que la Programación Orientada a Objetos fue el principio del fin de preocuparse por la endianidad ya que las capas de acceso y abstracción en un buen sistema OO ocultan detalles de implementación del usuario. Dado que la implementación incluye endianness, la gente se acostumbró a que no sea un factor explícito.

Anexo: zxcdw mencionó que la portabilidad es una preocupación. Sin embargo, ¿qué ha surgido con venganza en los últimos 20 años? Lenguajes de programación construidos en máquinas virtuales. Claro que la resistencia de la máquina virtual puede ser importante, pero se puede hacer muy consistente para ese idioma hasta el punto de que básicamente no es un problema. Solo los implementadores de VM tendrían que preocuparse por la resistencia desde el punto de vista de la portabilidad.

— Ingeniero mundial
fuente

2

Todavía hay muchos dominios muy relevantes en los que importa, por ejemplo, al escribir cualquier forma de código portátil. De hecho, lo que probablemente no importa es cuando se escribe código no portátil que está vinculado a una plataforma.

— zxcdw

@zxcdw que nos lleva directamente al ejército de lenguajes de máquinas virtuales ... No había pensado en eso.

— Ingeniero mundial

Su apéndice no es del todo cierto (y tampoco estoy de acuerdo con @zxcdw): la endianidad solo importa cuando se traduce entre enteros multibyte y flujos de bytes, y se convierte en un problema cuando se hace implícitamente y varía entre plataformas. La mayoría de los lenguajes modernos (ya sea basados en VM o no) logran la portabilidad al hacer que lo haga raramente (con números enteros como un tipo de datos opaco), y luego tienen endianness ya sea independiente de la plataforma o elegido explícitamente por el programador.

— Michael Borgwardt

2

@MichaelBorgwardt ARM hace arium.com/pdf/Endianness.pdf

— Ingeniero mundial

2

@zxcdw: incluso en el ensamblador, no siempre necesita conocer el orden endian. Las constantes, por ejemplo, no necesitan especificarse un byte a la vez. La situación es algo similar a un cierto estilo de serialización en C: x & 0xFFsiempre le da el byte menos significativo independientemente del orden endian (suponiendo que sus bytes sean de 8 bits cada uno) porque ha especificado los bits que le interesan por su valor, no su posición relativa en la memoria.

— Steve314

4

Endians solo importa cuando transfieres sistemas de datos binarios.

Con el avance de la velocidad del procesador (y un costo de almacenamiento mucho más bajo), las interfaces de datos binarios se están volviendo más raras para que no las note en la capa de aplicación. Está utilizando un formato de transferencia de texto (XML / JSON) o está utilizando la abstracción de la capa de datos que se encarga de la traducción por usted (por lo que ni siquiera se da cuenta de que hay una traducción).

Pero cuando está codificando en la capa de datos binarios, lo nota y es muy importante. Por ejemplo, cuando trabajé en VERITAS (Symantec ahora) estaba creando software que se estaba construyendo en 25 plataformas de hardware diferentes (no solo endian grande / pequeño, hay otros tipos).

— Martin York
fuente

Mis alumnos también se han desarrollado para teléfonos móviles y utilizan la informática en la nube, por lo que saben que el mundo no es PC y Mac.

— Ellen Spertus

@Loki: es posible serializar y deserializar sin conocer el endian de la máquina. Realmente solo necesita saber el orden de bytes de los datos en los archivos / flujos / lo que sea. Por ejemplo, (char) (x & 0xFF)en C le da el byte menos significativo independientemente de los problemas endianos, suponiendo solo que un byte es de 8 bits. Diseñé formatos de archivo binarios sin conocer las máquinas en las que se ejecutaría el software. Básicamente, elegí un pedido endian para el formato de archivo sin preocuparme por el hardware.

— Steve314

@espertus: Seguro posible.

— Martin York

1

@ Steve314: Sí, por supuesto que puedes. Cuando trabaje en la "capa de datos binarios", puede diseñar el esquema que desee para serializar sus datos y no es difícil diseñar esquemas que sean portables. Aunque personalmente no me molestaría en reinventar una rueda que ha sido construida y probada desde los años 60. Busque ` h2nl y familia. Esta familia de funciones proporciona una forma portátil (estándar) de hacer las cosas que es óptima para su plataforma.

— Martin York

4

No, nadie ha ganado. Nosotros, como especie, no hemos podido estandarizar el orden en el que almacenamos nuestros bytes, junto con la dirección en la que escribimos y el lado de la calle en la que conducimos.

Como consecuencia, cualquiera que quiera transferir datos entre dos sistemas diferentes a través de una red o en un archivo, tiene solo un 50% de posibilidades de que la versión inicial razonable de su código de descarga de datos sea correcta en su entorno, e incluso si funciona , tiene un 50% de posibilidades de trabajar en sus clientes.

Para lidiar con esto, debe buscar funciones específicas de la plataforma con nombres como "htonl" en los encabezados con nombres que obviamente datan de los años 70 como "arpa / inet.h", porque la situación no ha mejorado desde entonces y probablemente nunca lo hará. .

— Andrew Wagner
fuente

10

Resulta que hemos estandarizado: en lugar de enviar 4 bytes para representar un número entero, enviamos un bloque de texto formateado con texto de encabezado especial, corchetes angulares, palabras clave y una representación ASCII de esos 4 bytes. El extremo receptor analiza el formato para obtener el texto entero y lo convierte de nuevo en 4 bytes. Esto se llama progreso, me dicen :-)

— gbjbaanb

$ aptitude search xml | wc -l 677

— Andrew Wagner

1

Todavía no hay consenso:

La mayoría de los sistemas informáticos más grandes (servidor / computadora de escritorio / portátil) actualmente utilizan arquitecturas little endian
La mayoría de las computadoras más pequeñas (tabletas / teléfonos) usan una arquitectura de procesador independiente de endianness, pero ejecutan sistemas operativos que usan orden little endian

Entonces, a nivel de hardware, LE es mucho más común. Pero:

La mayoría de las comunicaciones entre computadoras se llevan a cabo utilizando protocolos que especifican el orden big-endian
Una proporción muy grande del software del mundo se ejecuta en una plataforma virtual que por defecto es de orden big-endian cada vez que los datos se escriben en almacenamiento externo.

Ambas órdenes van a estar con nosotros en el futuro previsible.

— Jules
fuente

La mayoría de los sistemas más grandes (es decir, "gran hierro") es típicamente big endian. Es decir, los llamados mini o sistemas mainframe (que constituyen una enorme cantidad de backend procesamiento de la mayoría de nosotros no se preocupan.)

@jdv Pero la mayoría de los sistemas informáticos más grandes son máquinas little endian x86-64, y allí, el rendimiento es importante.

— user877329

No creo que nadie pueda hacer ninguna afirmación firme de que la resistencia es nada más que conveniencia por parte de los diseñadores de arquitectura (para lo que quieran lograr). En el momento en que hice ese antiguo comentario, el hierro grande era BE. Pero esto no es porque sea BE, sino porque la arquitectura es así.