Re: [escepticos] endian-ness

["Adria Comos" <adriacomos@xxxxxxxxx>]

Buenas...

Little-endian viene de 'little end first', que viene a decir: el byte de
menor peso primero.  Esto quiere decir que en la arquitectura de ese sistema
los números 'multi-byte' se guardará el byte de menor peso en la posición de
memoria mas baja, el segundo byte de menos peso en el byte siguiente.... y
finalmente el byte de mayor peso en la última.

Esto hace que si representas el valor con un editor hexadecimal, que separa
los bytes individuales de la memoria y los visualiza en código hexadecimal
por separado, VISUALMENTE queden 'invertidos', ya que estos editores
muestran las posiciones de memoria empezando por la izquierda e
incrementando hacia la derecha.  Esto hace que, VISUALMENTE, los bytes de
menor peso (para enterdernos, las "unidades", "decenas".... -lo pongo entre
comillas pq no son realmente unidades ni decenas, pero bueno... es para no
liar) queden a la izquierda, y los "millares", "decenas de millar" a la
derecha, cosa que va en contra de la convención normal al escribir cualquier
cifra de toda la vida en papel y lapiz (los dígitos de mayor peso quedan a
la izquierda - .... millares->centenas->decenas->unidades).

Esto pasa con Intel.

Motorola, p.e, es un procesador 'big-endian', que es "big-end-first", o byte
de mayor peso primero.  Esto hace que los editores hexadecimales en esos
sistemas, que siguen colocando los bytes en pantalla de menor a mayor de
izquierda a derecha, en este caso SI que visualmente coincida con la
convención "histórica" de pintar las cifras con la mayor cifra a la
izquierda.

Esto sirve para editores hexadecimales, funciones que impriman valores
(printf y similares), etc...  Pero es sólo cuestión de visualización:
evidentemente, todos los sistemas son congruentes consigo mismos y da igual
como guarden los valores si los recuperan igual (como si los quieren guardar
solo en posiciones pares o encriptados por CPU....).

Pero el problema surge cuando estos sistemas deben compartir información
entre ellos de forma directa.  Por ello, cuando se pasan entre ellos
CUALQUIER tipo de archivo, debe haber en algun punto del software (otra cosa
es que se encuentre en un nivel transparente para nosotros en una libreria
que estemos utilizando, por el propio sistema, etc...) un procedimiento que
DEBE IDENTIFICAR el sistema que ha creado ese archivo para TRADUCIRLO al
nuestro.  Y por tanto, el archivo debe tener una marca de identificación de
quien lo ha creado.
En su defecto, tb es posible crear una convención de que al pasarlo a cierto
medio (p.e, una red TCP), se seguirá una normativa fija (p.e, parece ser que
big endian para TCP - esto no lo conocía...).  Evidentemente, la traducción
se sigue haciendo, aunque en este caso se puede hacer justo a la hora de
pasar a la red y/o a la hora de recuperar la información en el receptor.
Pero claro, si esta convención no existe debe haber la marca para cada
archivo...

Enga... perdón por el rollo ;-)


----- Original Message ----- 
From: "José Ángel Morente" <msxjam@xxxxxxxxx>
To: <escepticos@xxxxxxxxxxxx>
Sent: Monday, June 06, 2005 10:39 AM
Subject: Re: [escepticos] endian-ness


> txipi wrote:
>
> > Obviamente, si intentas no leer el fichero byte a byte, será difícil ver
> > la endian-ness de una arquitectura, porque cuando almacenas un 1 en un
> > entero de 32 bits, por mucho que internamente se guarde como 01000000 o
> > 00000001, al recuperarlo tendrás el 1 original, así que estamos en las
> > mismas.
>
> Claro, sólo mirando con un editor hex agrupando el contenido en bytes
> individuales puede verse lo que estáis comentando. Cuando cargas el dato
> en un registro, se carga "en su orden", independientemente de cómo esté
> guardado en la memoria.
>
>
> Yo a estas alturas todavía confundo la terminología "little-endian" y
> "big-endian" cuando se trata de nombrarlos. Pero lo que sí tengo muy
> claro es que en 68000 se guarda como AA BB CC DD y en Intel o en Zilog
> se ve como DD CC BB AA.
>
> Como decía el anuncio, "el editor hexadecimal no engaña..."
>
> :D
>
>
> > De todas maneras, esto no creo que interese a nadie O:-)
>
> ¿Estás seguro? ;-)