Le Tue, 26 Apr 2011 14:48:57 +0200, Antoine Leca écrivait :
Marc Espie écrivit :
Bon apres, deja, en passant de __i386 a __BYTE_ORDER, il y a deja un progres, parce que quid de i386/powerpc/arm/sparc64/longsoon/superH pour ne citer que quelques archis couramment en usage ces jours-ci ?
<TAQUIN> D'après http://www.openbsd.org/cgi-bin/man.cgi?query¾toh64, rubrique BUGS, il n'y a que "vax, alpha, i386, and some mips architectures," qui diffèrent du reste du monde. :-) </TAQUIN>
{Et oui, je sais que ce texte vient en droite ligne de la page byteorder(3) de 4.2BSD, et qu'à l'époque il importait de pouvoir facilement lire les dumps binaires à l'écran.}
<LINUX> man endian ? </LINUX>
J'ai la flemme de redémarrer ma SS20 qui tourne sous NetBSD (et seulement en 32 bits...)...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Le Tue, 26 Apr 2011 14:48:57 +0200,
Antoine Leca <root@localhost.invalid> écrivait :
Marc Espie écrivit :
Bon apres, deja, en passant de __i386 a __BYTE_ORDER, il y a deja un progres,
parce que quid de i386/powerpc/arm/sparc64/longsoon/superH pour ne citer que
quelques archis couramment en usage ces jours-ci ?
<TAQUIN>
D'après http://www.openbsd.org/cgi-bin/man.cgi?query¾toh64, rubrique
BUGS, il n'y a que "vax, alpha, i386, and some mips architectures," qui
diffèrent du reste du monde. :-)
</TAQUIN>
{Et oui, je sais que ce texte vient en droite ligne de la page
byteorder(3) de 4.2BSD, et qu'à l'époque il importait de pouvoir
facilement lire les dumps binaires à l'écran.}
<LINUX>
man endian ?
</LINUX>
J'ai la flemme de redémarrer ma SS20 qui tourne sous NetBSD (et
seulement en 32 bits...)...
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Le Tue, 26 Apr 2011 14:48:57 +0200, Antoine Leca écrivait :
Marc Espie écrivit :
Bon apres, deja, en passant de __i386 a __BYTE_ORDER, il y a deja un progres, parce que quid de i386/powerpc/arm/sparc64/longsoon/superH pour ne citer que quelques archis couramment en usage ces jours-ci ?
<TAQUIN> D'après http://www.openbsd.org/cgi-bin/man.cgi?query¾toh64, rubrique BUGS, il n'y a que "vax, alpha, i386, and some mips architectures," qui diffèrent du reste du monde. :-) </TAQUIN>
{Et oui, je sais que ce texte vient en droite ligne de la page byteorder(3) de 4.2BSD, et qu'à l'époque il importait de pouvoir facilement lire les dumps binaires à l'écran.}
<LINUX> man endian ? </LINUX>
J'ai la flemme de redémarrer ma SS20 qui tourne sous NetBSD (et seulement en 32 bits...)...
JKB
-- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr
Samuel DEVULDER
Le 26/04/2011 14:56, JKB a écrit :
<LINUX> man endian ? </LINUX>
J'ai la flemme de redémarrer ma SS20 qui tourne sous NetBSD (et seulement en 32 bits...)...
Il faudrait parler du byte-order du PDP-11 (la machine sur laquelle le C est né): ni little, ni big, mais mélangé! 0xAABBCCDD est ainsi stocké 0xBB 0xAA 0xDD 0xCC (adresses croissantes).
sam.
Le 26/04/2011 14:56, JKB a écrit :
<LINUX>
man endian ?
</LINUX>
J'ai la flemme de redémarrer ma SS20 qui tourne sous NetBSD (et
seulement en 32 bits...)...
Il faudrait parler du byte-order du PDP-11 (la machine sur laquelle le C
est né): ni little, ni big, mais mélangé! 0xAABBCCDD est ainsi stocké
0xBB 0xAA 0xDD 0xCC (adresses croissantes).
J'ai la flemme de redémarrer ma SS20 qui tourne sous NetBSD (et seulement en 32 bits...)...
Il faudrait parler du byte-order du PDP-11 (la machine sur laquelle le C est né): ni little, ni big, mais mélangé! 0xAABBCCDD est ainsi stocké 0xBB 0xAA 0xDD 0xCC (adresses croissantes).
sam.
Erwan David
Samuel DEVULDER écrivait :
Le 26/04/2011 14:56, JKB a écrit :
<LINUX> man endian ? </LINUX>
J'ai la flemme de redémarrer ma SS20 qui tourne sous NetBSD (et seulement en 32 bits...)...
Il faudrait parler du byte-order du PDP-11 (la machine sur laquelle le C est né): ni little, ni big, mais mélangé! 0xAABBCCDD est ainsi stocké 0xBB 0xAA 0xDD 0xCC (adresses croissantes).
Il me semble qu'il y a un paragraphe sur les byte order au début de la norme ISO/IEC 20970 (ça défini un format de code Java pour de l'embarqué). Avec une palanquée de cas...
(purée 142 CHF pour ça...)
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Samuel DEVULDER <samuel-dot-devulder@laposte-dot-com> écrivait :
Le 26/04/2011 14:56, JKB a écrit :
<LINUX>
man endian ?
</LINUX>
J'ai la flemme de redémarrer ma SS20 qui tourne sous NetBSD (et
seulement en 32 bits...)...
Il faudrait parler du byte-order du PDP-11 (la machine sur laquelle le
C est né): ni little, ni big, mais mélangé! 0xAABBCCDD est ainsi
stocké 0xBB 0xAA 0xDD 0xCC (adresses croissantes).
Il me semble qu'il y a un paragraphe sur les byte order au début de la
norme ISO/IEC 20970 (ça défini un format de code Java pour de
l'embarqué). Avec une palanquée de cas...
(purée 142 CHF pour ça...)
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
J'ai la flemme de redémarrer ma SS20 qui tourne sous NetBSD (et seulement en 32 bits...)...
Il faudrait parler du byte-order du PDP-11 (la machine sur laquelle le C est né): ni little, ni big, mais mélangé! 0xAABBCCDD est ainsi stocké 0xBB 0xAA 0xDD 0xCC (adresses croissantes).
Il me semble qu'il y a un paragraphe sur les byte order au début de la norme ISO/IEC 20970 (ça défini un format de code Java pour de l'embarqué). Avec une palanquée de cas...
(purée 142 CHF pour ça...)
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Antoine Leca
Samuel DEVULDER écrivit :
Il faudrait parler du byte-order du PDP-11
Ce n'est pas le PDP-11 (une machine 16-bit petit-boutien, qui ne sait pas lire ou écrire de valeurs 32 bits en mémoire, exactement comme les Intel 8086/186/286), mais le coprocesseur FP-11 qui utilise cet ordre bizarre (67452301 pour les doubles). Le VAX utilise aussi cet ordre pour les nombres flottants, pour la compatibilité ascendante.
Unix V5 a alors choisi par imitation de stocker les deux morceaux des entiers 32 bits (time_t puis off_t) dans l'ordre « visuel » des humains, ce qui a donné l'ordre bizarre "NUXI" pour les entiers 32-bits mais d'autres systèmes PDP-11 utilisaient l'ordre petit-boutien de manière cohérente.
Antoine
Samuel DEVULDER écrivit :
Il faudrait parler du byte-order du PDP-11
Ce n'est pas le PDP-11 (une machine 16-bit petit-boutien, qui ne sait
pas lire ou écrire de valeurs 32 bits en mémoire, exactement comme les
Intel 8086/186/286), mais le coprocesseur FP-11 qui utilise cet ordre
bizarre (67452301 pour les doubles). Le VAX utilise aussi cet ordre pour
les nombres flottants, pour la compatibilité ascendante.
Unix V5 a alors choisi par imitation de stocker les deux morceaux des
entiers 32 bits (time_t puis off_t) dans l'ordre « visuel » des humains,
ce qui a donné l'ordre bizarre "NUXI" pour les entiers 32-bits mais
d'autres systèmes PDP-11 utilisaient l'ordre petit-boutien de manière
cohérente.
Ce n'est pas le PDP-11 (une machine 16-bit petit-boutien, qui ne sait pas lire ou écrire de valeurs 32 bits en mémoire, exactement comme les Intel 8086/186/286), mais le coprocesseur FP-11 qui utilise cet ordre bizarre (67452301 pour les doubles). Le VAX utilise aussi cet ordre pour les nombres flottants, pour la compatibilité ascendante.
Unix V5 a alors choisi par imitation de stocker les deux morceaux des entiers 32 bits (time_t puis off_t) dans l'ordre « visuel » des humains, ce qui a donné l'ordre bizarre "NUXI" pour les entiers 32-bits mais d'autres systèmes PDP-11 utilisaient l'ordre petit-boutien de manière cohérente.
Antoine
Samuel DEVULDER
Le 27/04/2011 13:12, Antoine Leca a écrit :
Samuel DEVULDER écrivit :
Il faudrait parler du byte-order du PDP-11
Ce n'est pas le PDP-11 (une machine 16-bit petit-boutien, qui ne sait pas lire ou écrire de valeurs 32 bits en mémoire, exactement comme les Intel 8086/186/286), mais le coprocesseur FP-11 qui utilise cet ordre bizarre (67452301 pour les doubles). Le VAX utilise aussi cet ordre pour les nombres flottants, pour la compatibilité ascendante.
merci pour le complément d'info. Il faudra réparer la wiki à propos du PDP-11. http://en.wikipedia.org/wiki/Endianness#Middle-endian
sam.
Le 27/04/2011 13:12, Antoine Leca a écrit :
Samuel DEVULDER écrivit :
Il faudrait parler du byte-order du PDP-11
Ce n'est pas le PDP-11 (une machine 16-bit petit-boutien, qui ne sait
pas lire ou écrire de valeurs 32 bits en mémoire, exactement comme les
Intel 8086/186/286), mais le coprocesseur FP-11 qui utilise cet ordre
bizarre (67452301 pour les doubles). Le VAX utilise aussi cet ordre pour
les nombres flottants, pour la compatibilité ascendante.
merci pour le complément d'info. Il faudra réparer la wiki à propos du
PDP-11. http://en.wikipedia.org/wiki/Endianness#Middle-endian
Ce n'est pas le PDP-11 (une machine 16-bit petit-boutien, qui ne sait pas lire ou écrire de valeurs 32 bits en mémoire, exactement comme les Intel 8086/186/286), mais le coprocesseur FP-11 qui utilise cet ordre bizarre (67452301 pour les doubles). Le VAX utilise aussi cet ordre pour les nombres flottants, pour la compatibilité ascendante.
merci pour le complément d'info. Il faudra réparer la wiki à propos du PDP-11. http://en.wikipedia.org/wiki/Endianness#Middle-endian
