big/little endian

James Kanze

23/10/2004 à 19:25

Jean-Marc Bourguet writes:

|> James Kanze writes:

|> > |> Oui. On utilise alors des pointeurs vers char qui contiennent
|> > |> plus d'info. C'est a cause de ce genre de machines qu'on peut
|> > |> avoir sizeof (int*) < sizeof(char*). Les C pour PDP-10 que
|> > |> j'ai vu (j'ai pas utilise le C sur ces machines mais des
|> > |> compilateurs C pour elles existent) ont CHAR_BIT==9 et
|> > |> sizeof(int)==4; mais ces machines etaient utilise avec de
|> > |> l'ASCII, 7 bits, 5 char par mot + 1 bit de padding ou du 6
|> > |> bits , 6 char par mots et il me semble me souvenir qu'il etait
|> > |> possible de mettre les compilo C dans un mode plus compatible
|> > |> avec le systeme meme si moins conforme a l'ISO.

|> > Sur le C pour le PDP-10 que j'ai vu, la taille des pointeurs était
|> > toujours 24 bits. En revanche, il n'y avait que les bits de poids
|> > faibles (j'en oublies combien) qui servait pour l'adressage des
|> > mots ; certains bits de poids fort servaient à selectionner les
|> > bytes dans le mot, le cas échéant (les char*). Ce qui donnait la
|> > situation que si p était un char*, "(int)p > (int)( p+1 )" pour
|> > certains valeurs de p.

(Je me suis trompé en fait sur la taille. C'était 36 bits, évidemment.
Mais quelle était alors la machine à 24 bits ?)

|> (Toujours de mémoire, donc sujet à erreur, et je répète que je n'ai
|> pas programmé cette machine en C, donc ça diminue d'autant la
|> qualité de mes souvenirs sur le C)

Moi, je n'en ai même jamais eu sous la main. Mes souvenirs ne concernent
que ce que l'ai lu. Il y a peu de temps, d'ailleurs.

Enfin, c'est facile à vérifier :
http://www.inwap.com/pdp10/hbaker/pdp-10/pdp-10.html.

|> Le PDP-10 permettait l'adressage indirect dans toute sa splendeur.
|> Les champs définissant une adresse dans une instruction était au
|> nombre de 3: une valeur immédiate sur 18 bits, un registre (le
|> registre 0 n'était pas disponible pour ça, son utilisation marquait
|> l'absence de registre). L'adresse était la somme des deux. Le
|> troisième champs indiquait qu'en fait il fallait récupérer l'adresse
|> en mémoire à l'adresse juste calculée. L'adresse en mémoire était
|> dans le format des champs définissant les adresses dans les
|> instructions, avec la possibilité d'une nouvelle indexation sur un
|> registre et d'une nouvelle indirection...

|> Les instructions manipulant des chars devaient nécessairement faire
|> référence à un mot en mémoire. Une partie (ou tous?) des bits
|> autrement ignorés lors du calcul d'adresse de celui-ci désignaient
|> la taille du char et sa position dans le mot.

Les instructions manipulant des « bytes » avaient toujours une
indirection en plus -- l'adresse dans l'instruction était l'adresse d'un
« byte pointer », un mot de 36 bits avec un champ pour la position, et
un champ pour la taille.

J'imagine qu'un char* aurait eu exactement le format d'un « byte
pointer ».

Note que si je comprends la documentation à la site ci-dessus
correctement, la position était bien sur les poids faibles du mot. Or,
je me rappelle bien avoir parlé avec quelqu'un qui m'a racconté d'une
architecture à peu près semblable, mais avec la position aux poids
forts. De façon que quand tu incrémentais un pointeur de byte la
première fois, c'était bien dans les poids forts où l'incrémentation
avait lieu, et que (unsigned)p > (unsigned)(p+1).

|> Vous pensez que c'est compliqué? Je n'ai pas abordé le sujet de
|> l'adressage étendu (dont je n'ai que des vagues souvenirs)
|> permettant des adresses sur plus de 18 bits.

Il y en avait sur les PDP-10 aussi. Je m'en souviens bien sur les PDP-11
(et sur prèsque toutes les machines de 16 bits).

Mais en fait, les IA-32 ont encore quelque chose de semblable, qui sert
pour permettre des adresses de plus de 32 bits. Et même si Windows et
Linux préfère en ignorer l'existance, je m'en suis déjà servi.

|> > (Sur le PDP-10, grosso modo, le poids fort d'un mot était ignoré
|> > dans la plupart des adressages. Dans le cas des instructions load
|> > byte et store byte, en revanche, une partie du poid fort spécifier
|> > l'offset du premier bit, et une autre partie le nombre de bits
|> > concerné. En C, évidemment, le nombre de bits concerné était
|> > toujours 9, mais dans la plupart des autres langages, on utilisait
|> > 6.)

|> Je crois que ça dépendait aussi de l'OS. TOPS-20 (que j'ai utilisé)
|> c'était généralement ASCII 7 bits (5 char par mot et un bit -- celui
|> de poids faible si j'ai bonne mémoire -- ignoré). Mais à certains
|> endroits il y avait du SIXBIT, provenant probablement de TOPS-10.

En effet, la documentation des instructions à byte dit que « Text
strings are typically stored using seven-bit bytes, five per word. »
Je ne sais pas d'où j'ai tiré les six bits. (Je sais qu'un des premiers
IBM utilisait des mots de 36 bits aussi. Avec six bytes de six bits.
C'est le processeur où on a inventé le Fortran, et ça explique d'une
part pourquio le Fortran utilise si peu de caractères, et de l'autre
pourquoi il utilise des symbols de six caractères maximum.)

|> Je suis quasiment certains d'avoir vu un compilo C avec un switch
|> permettant de choisir la taille des char entre au moins 9, 7 et 6

Ça aurait du être amusant. Et les gens se plaignent des problèmes de
portabilité entre les Sparc et les Intel.

|> > |> Alternativement on peut naturellement les faire fonctionner
|> > |> avec des chars equivalent au mot.

|> > C'était quand même assez rare sur les machines à vocation générale.

|> Effectivement, "assez rare" comme dans "je n'en connais pas".

C'est souvent la définition que j'utilise (comme Gaby ne tarde jamais à
me rappeler).

En fait, on pourrait dire que sur un IBM 1401, les chars équivalaient au
mot. Mais seulement parce que le seul « mot » sur ces machines n'avait
que six (ou sept, ou huit, selon ce que tu comptais) bits. Les
« nombres » sur la machine était décimaux, normalement non-packé, sur
une suite de « mots », avec un flag de fin. Il n'y avait aucun
arithmétique binaire.

En revanche, je ne crois pas qu'il a jamais eu un compilateur (C ou
autre).

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Jean-Marc Bourguet <jm@bourguet.org> writes:

|> James Kanze <james.kanze@free.fr> writes:

|> > |> Oui. On utilise alors des pointeurs vers char qui contiennent
|> > |> plus d'info. C'est a cause de ce genre de machines qu'on peut
|> > |> avoir sizeof (int*) < sizeof(char*). Les C pour PDP-10 que
|> > |> j'ai vu (j'ai pas utilise le C sur ces machines mais des
|> > |> compilateurs C pour elles existent) ont CHAR_BIT==9 et
|> > |> sizeof(int)==4; mais ces machines etaient utilise avec de
|> > |> l'ASCII, 7 bits, 5 char par mot + 1 bit de padding ou du 6
|> > |> bits , 6 char par mots et il me semble me souvenir qu'il etait
|> > |> possible de mettre les compilo C dans un mode plus compatible
|> > |> avec le systeme meme si moins conforme a l'ISO.

|> > Sur le C pour le PDP-10 que j'ai vu, la taille des pointeurs était
|> > toujours 24 bits. En revanche, il n'y avait que les bits de poids
|> > faibles (j'en oublies combien) qui servait pour l'adressage des
|> > mots ; certains bits de poids fort servaient à selectionner les
|> > bytes dans le mot, le cas échéant (les char*). Ce qui donnait la
|> > situation que si p était un char*, "(int)p > (int)( p+1 )" pour
|> > certains valeurs de p.

(Je me suis trompé en fait sur la taille. C'était 36 bits, évidemment.
Mais quelle était alors la machine à 24 bits ?)

|> (Toujours de mémoire, donc sujet à erreur, et je répète que je n'ai
|> pas programmé cette machine en C, donc ça diminue d'autant la
|> qualité de mes souvenirs sur le C)

Moi, je n'en ai même jamais eu sous la main. Mes souvenirs ne concernent
que ce que l'ai lu. Il y a peu de temps, d'ailleurs.

Enfin, c'est facile à vérifier :
http://www.inwap.com/pdp10/hbaker/pdp-10/pdp-10.html.

|> Le PDP-10 permettait l'adressage indirect dans toute sa splendeur.
|> Les champs définissant une adresse dans une instruction était au
|> nombre de 3: une valeur immédiate sur 18 bits, un registre (le
|> registre 0 n'était pas disponible pour ça, son utilisation marquait
|> l'absence de registre). L'adresse était la somme des deux. Le
|> troisième champs indiquait qu'en fait il fallait récupérer l'adresse
|> en mémoire à l'adresse juste calculée. L'adresse en mémoire était
|> dans le format des champs définissant les adresses dans les
|> instructions, avec la possibilité d'une nouvelle indexation sur un
|> registre et d'une nouvelle indirection...

|> Les instructions manipulant des chars devaient nécessairement faire
|> référence à un mot en mémoire. Une partie (ou tous?) des bits
|> autrement ignorés lors du calcul d'adresse de celui-ci désignaient
|> la taille du char et sa position dans le mot.

Les instructions manipulant des « bytes » avaient toujours une
indirection en plus -- l'adresse dans l'instruction était l'adresse d'un
« byte pointer », un mot de 36 bits avec un champ pour la position, et
un champ pour la taille.

J'imagine qu'un char* aurait eu exactement le format d'un « byte
pointer ».

Note que si je comprends la documentation à la site ci-dessus
correctement, la position était bien sur les poids faibles du mot. Or,
je me rappelle bien avoir parlé avec quelqu'un qui m'a racconté d'une
architecture à peu près semblable, mais avec la position aux poids
forts. De façon que quand tu incrémentais un pointeur de byte la
première fois, c'était bien dans les poids forts où l'incrémentation
avait lieu, et que (unsigned)p > (unsigned)(p+1).

|> Vous pensez que c'est compliqué? Je n'ai pas abordé le sujet de
|> l'adressage étendu (dont je n'ai que des vagues souvenirs)
|> permettant des adresses sur plus de 18 bits.

Il y en avait sur les PDP-10 aussi. Je m'en souviens bien sur les PDP-11
(et sur prèsque toutes les machines de 16 bits).

Mais en fait, les IA-32 ont encore quelque chose de semblable, qui sert
pour permettre des adresses de plus de 32 bits. Et même si Windows et
Linux préfère en ignorer l'existance, je m'en suis déjà servi.

|> > (Sur le PDP-10, grosso modo, le poids fort d'un mot était ignoré
|> > dans la plupart des adressages. Dans le cas des instructions load
|> > byte et store byte, en revanche, une partie du poid fort spécifier
|> > l'offset du premier bit, et une autre partie le nombre de bits
|> > concerné. En C, évidemment, le nombre de bits concerné était
|> > toujours 9, mais dans la plupart des autres langages, on utilisait
|> > 6.)

|> Je crois que ça dépendait aussi de l'OS. TOPS-20 (que j'ai utilisé)
|> c'était généralement ASCII 7 bits (5 char par mot et un bit -- celui
|> de poids faible si j'ai bonne mémoire -- ignoré). Mais à certains
|> endroits il y avait du SIXBIT, provenant probablement de TOPS-10.

En effet, la documentation des instructions à byte dit que « Text
strings are typically stored using seven-bit bytes, five per word. »
Je ne sais pas d'où j'ai tiré les six bits. (Je sais qu'un des premiers
IBM utilisait des mots de 36 bits aussi. Avec six bytes de six bits.
C'est le processeur où on a inventé le Fortran, et ça explique d'une
part pourquio le Fortran utilise si peu de caractères, et de l'autre
pourquoi il utilise des symbols de six caractères maximum.)

|> Je suis quasiment certains d'avoir vu un compilo C avec un switch
|> permettant de choisir la taille des char entre au moins 9, 7 et 6

Ça aurait du être amusant. Et les gens se plaignent des problèmes de
portabilité entre les Sparc et les Intel.

|> > |> Alternativement on peut naturellement les faire fonctionner
|> > |> avec des chars equivalent au mot.

|> > C'était quand même assez rare sur les machines à vocation générale.

|> Effectivement, "assez rare" comme dans "je n'en connais pas".

C'est souvent la définition que j'utilise (comme Gaby ne tarde jamais à
me rappeler).

En fait, on pourrait dire que sur un IBM 1401, les chars équivalaient au
mot. Mais seulement parce que le seul « mot » sur ces machines n'avait
que six (ou sept, ou huit, selon ce que tu comptais) bits. Les
« nombres » sur la machine était décimaux, normalement non-packé, sur
une suite de « mots », avec un flag de fin. Il n'y avait aucun
arithmétique binaire.

En revanche, je ne crois pas qu'il a jamais eu un compilateur (C ou
autre).

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Vous avez filtré cet utilisateur ! Consultez son message

Jean-Marc Bourguet writes:

|> James Kanze writes:

|> > |> Oui. On utilise alors des pointeurs vers char qui contiennent
|> > |> plus d'info. C'est a cause de ce genre de machines qu'on peut
|> > |> avoir sizeof (int*) < sizeof(char*). Les C pour PDP-10 que
|> > |> j'ai vu (j'ai pas utilise le C sur ces machines mais des
|> > |> compilateurs C pour elles existent) ont CHAR_BIT==9 et
|> > |> sizeof(int)==4; mais ces machines etaient utilise avec de
|> > |> l'ASCII, 7 bits, 5 char par mot + 1 bit de padding ou du 6
|> > |> bits , 6 char par mots et il me semble me souvenir qu'il etait
|> > |> possible de mettre les compilo C dans un mode plus compatible
|> > |> avec le systeme meme si moins conforme a l'ISO.

|> > Sur le C pour le PDP-10 que j'ai vu, la taille des pointeurs était
|> > toujours 24 bits. En revanche, il n'y avait que les bits de poids
|> > faibles (j'en oublies combien) qui servait pour l'adressage des
|> > mots ; certains bits de poids fort servaient à selectionner les
|> > bytes dans le mot, le cas échéant (les char*). Ce qui donnait la
|> > situation que si p était un char*, "(int)p > (int)( p+1 )" pour
|> > certains valeurs de p.

(Je me suis trompé en fait sur la taille. C'était 36 bits, évidemment.
Mais quelle était alors la machine à 24 bits ?)

|> (Toujours de mémoire, donc sujet à erreur, et je répète que je n'ai
|> pas programmé cette machine en C, donc ça diminue d'autant la
|> qualité de mes souvenirs sur le C)

Moi, je n'en ai même jamais eu sous la main. Mes souvenirs ne concernent
que ce que l'ai lu. Il y a peu de temps, d'ailleurs.

Enfin, c'est facile à vérifier :
http://www.inwap.com/pdp10/hbaker/pdp-10/pdp-10.html.

|> Le PDP-10 permettait l'adressage indirect dans toute sa splendeur.
|> Les champs définissant une adresse dans une instruction était au
|> nombre de 3: une valeur immédiate sur 18 bits, un registre (le
|> registre 0 n'était pas disponible pour ça, son utilisation marquait
|> l'absence de registre). L'adresse était la somme des deux. Le
|> troisième champs indiquait qu'en fait il fallait récupérer l'adresse
|> en mémoire à l'adresse juste calculée. L'adresse en mémoire était
|> dans le format des champs définissant les adresses dans les
|> instructions, avec la possibilité d'une nouvelle indexation sur un
|> registre et d'une nouvelle indirection...

|> Les instructions manipulant des chars devaient nécessairement faire
|> référence à un mot en mémoire. Une partie (ou tous?) des bits
|> autrement ignorés lors du calcul d'adresse de celui-ci désignaient
|> la taille du char et sa position dans le mot.

Les instructions manipulant des « bytes » avaient toujours une
indirection en plus -- l'adresse dans l'instruction était l'adresse d'un
« byte pointer », un mot de 36 bits avec un champ pour la position, et
un champ pour la taille.

J'imagine qu'un char* aurait eu exactement le format d'un « byte
pointer ».

Note que si je comprends la documentation à la site ci-dessus
correctement, la position était bien sur les poids faibles du mot. Or,
je me rappelle bien avoir parlé avec quelqu'un qui m'a racconté d'une
architecture à peu près semblable, mais avec la position aux poids
forts. De façon que quand tu incrémentais un pointeur de byte la
première fois, c'était bien dans les poids forts où l'incrémentation
avait lieu, et que (unsigned)p > (unsigned)(p+1).

|> Vous pensez que c'est compliqué? Je n'ai pas abordé le sujet de
|> l'adressage étendu (dont je n'ai que des vagues souvenirs)
|> permettant des adresses sur plus de 18 bits.

Il y en avait sur les PDP-10 aussi. Je m'en souviens bien sur les PDP-11
(et sur prèsque toutes les machines de 16 bits).

Mais en fait, les IA-32 ont encore quelque chose de semblable, qui sert
pour permettre des adresses de plus de 32 bits. Et même si Windows et
Linux préfère en ignorer l'existance, je m'en suis déjà servi.

|> > (Sur le PDP-10, grosso modo, le poids fort d'un mot était ignoré
|> > dans la plupart des adressages. Dans le cas des instructions load
|> > byte et store byte, en revanche, une partie du poid fort spécifier
|> > l'offset du premier bit, et une autre partie le nombre de bits
|> > concerné. En C, évidemment, le nombre de bits concerné était
|> > toujours 9, mais dans la plupart des autres langages, on utilisait
|> > 6.)

|> Je crois que ça dépendait aussi de l'OS. TOPS-20 (que j'ai utilisé)
|> c'était généralement ASCII 7 bits (5 char par mot et un bit -- celui
|> de poids faible si j'ai bonne mémoire -- ignoré). Mais à certains
|> endroits il y avait du SIXBIT, provenant probablement de TOPS-10.

En effet, la documentation des instructions à byte dit que « Text
strings are typically stored using seven-bit bytes, five per word. »
Je ne sais pas d'où j'ai tiré les six bits. (Je sais qu'un des premiers
IBM utilisait des mots de 36 bits aussi. Avec six bytes de six bits.
C'est le processeur où on a inventé le Fortran, et ça explique d'une
part pourquio le Fortran utilise si peu de caractères, et de l'autre
pourquoi il utilise des symbols de six caractères maximum.)

|> Je suis quasiment certains d'avoir vu un compilo C avec un switch
|> permettant de choisir la taille des char entre au moins 9, 7 et 6

Ça aurait du être amusant. Et les gens se plaignent des problèmes de
portabilité entre les Sparc et les Intel.

|> > |> Alternativement on peut naturellement les faire fonctionner
|> > |> avec des chars equivalent au mot.

|> > C'était quand même assez rare sur les machines à vocation générale.

|> Effectivement, "assez rare" comme dans "je n'en connais pas".

C'est souvent la définition que j'utilise (comme Gaby ne tarde jamais à
me rappeler).

En fait, on pourrait dire que sur un IBM 1401, les chars équivalaient au
mot. Mais seulement parce que le seul « mot » sur ces machines n'avait
que six (ou sept, ou huit, selon ce que tu comptais) bits. Les
« nombres » sur la machine était décimaux, normalement non-packé, sur
une suite de « mots », avec un flag de fin. Il n'y avait aucun
arithmétique binaire.

En revanche, je ne crois pas qu'il a jamais eu un compilateur (C ou
autre).

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

James Kanze

23/10/2004 à 19:26

Jean-Marc Bourguet writes:

|> James Kanze writes:

|> > Jean-Marc Bourguet writes:

|> > |> Il y a quelques processeurs (en fait seul le 8051 me vient a
|> > |> l'esprit pour le moment) qui permette d'acceder aux bits
|> > |> individuellement. Dans ces cas l'ordre peut avoir de
|> > |> l'importance.

|> > Et le PDP-10 ?

|> J'aurais dû y penser. Mais avec le 8051 en tête (il permet de faire
|> des opérations directement sur des bits, c'est un micro-controleur
|> après tout) ses capacités à ce niveau sont faibles -- simplement la
|> lecture et l'écriture accompagnée éventuellement d'une
|> incrémentation du pointeur si j'ai bonne mémoire.

À peu près. Mais apparamment, la possibilité d'extraire un champs de
bits (indépendamment de son utilisation pour des chars) était assez
intéressante pour qu'ils l'implémentent aussi sur la VAX.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Jean-Marc Bourguet

23/10/2004 à 19:48

James Kanze writes:

(Je me suis trompé en fait sur la taille. C'était 36 bits,
évidemment. Mais quelle était alors la machine à 24
bits?)

Je n'en sais rien. Il me semble que Digital en a fait.

|> (Toujours de mémoire, donc sujet à erreur, et je
|> répète que je n'ai pas programmé cette machine en C,
|> donc ça diminue d'autant la qualité de mes souvenirs
|> sur le C)

Moi, je n'en ai même jamais eu sous la main. Mes souvenirs
ne concernent que ce que l'ai lu. Il y a peu de temps,
d'ailleurs.

C'est le premier ordinateur sur lequel j'ai eu des cours.
L'année d'après j'ai changé d'unif et là c'était sur VAX.

[...]

J'imagine qu'un char* aurait eu exactement le format d'un « byte
pointer ».

Je ne vois pas comment faire autrement de manière pratique.

Note que si je comprends la documentation à la site
ci-dessus correctement, la position était bien sur les
poids faibles du mot. Or, je me rappelle bien avoir parlé
avec quelqu'un qui m'a racconté d'une architecture à peu
près semblable, mais avec la position aux poids forts. De
façon que quand tu incrémentais un pointeur de byte la
première fois, c'était bien dans les poids forts où
l'incrémentation avait lieu, et que (unsigned)p >
(unsigned)(p+1).

Quand je lis:

A byte pointer has the following format:

000000 000011 1 1 1111 112222222222333333
012345 678901 2 3 4567 890123456789012345
_________________________________________
| | | | | | |
| POS | SIZE |U|I| X | Y |
|______|______|_|_|____|__________________|

POS is the byte position: the number of bits from the right
end of the byte to the right end of the word.

Je comprends que la position se trouve bien dans les bits de
poids forts (le PDP-10 est grand boutien dans sa
numérotation des bits). Le contraire aurait contredit mes
souvenirs.

|> Vous pensez que c'est compliqué? Je n'ai pas abordé le
|> sujet de l'adressage étendu (dont je n'ai que des
|> vagues souvenirs) permettant des adresses sur plus de
|> 18 bits.

Il y en avait sur les PDP-10 aussi.

C'est ce que je dis. Mais je ne suis plus capable de
décrire comment ça fonctionnait, en particulier pour les
pointeurs de byte.

Je m'en souviens bien sur les PDP-11 (et sur prèsque
toutes les machines de 16 bits).

Mais en fait, les IA-32 ont encore quelque chose de
semblable, qui sert pour permettre des adresses de plus de
32 bits. Et même si Windows et Linux préfère en ignorer
l'existance, je m'en suis déjà servi.

Jamais utilisé ça, mais j'avais cru comprendre que c'était
simplement le mapping adresse virtuelle -> adresse physique
qui permettait d'avoir plus de 32 bits d'adresse physique et
que l'espace mémoire virtuel était bien limité à 32 bits.

Sur les premiers PDP-10, l'espace mémoire virtuel était de
18 bits. Sur les derniers, l'espace mémoire virtuel était
plus large (j'ai le vague souvenir de 30 bits) avec de la
segmentation et de calcul d'adresse différent suivant le
segment dans lequel on était.

[...]

En fait, on pourrait dire que sur un IBM 1401, les chars
équivalaient au mot. Mais seulement parce que le seul «
mot » sur ces machines n'avait que six (ou sept, ou huit,
selon ce que tu comptais) bits. Les « nombres » sur la
machine était décimaux, normalement non-packé, sur une
suite de « mots », avec un flag de fin. Il n'y avait aucun
arithmétique binaire.

Je ne connaissais pas. C'est ce genre de machines qu'on
appelait des machines commerciales (opposées aux machines
scientifiques)?

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

James Kanze <james.kanze@free.fr> writes:

(Je me suis trompé en fait sur la taille. C'était 36 bits,
évidemment. Mais quelle était alors la machine à 24
bits?)

Je n'en sais rien. Il me semble que Digital en a fait.

|> (Toujours de mémoire, donc sujet à erreur, et je
|> répète que je n'ai pas programmé cette machine en C,
|> donc ça diminue d'autant la qualité de mes souvenirs
|> sur le C)

Moi, je n'en ai même jamais eu sous la main. Mes souvenirs
ne concernent que ce que l'ai lu. Il y a peu de temps,
d'ailleurs.

C'est le premier ordinateur sur lequel j'ai eu des cours.
L'année d'après j'ai changé d'unif et là c'était sur VAX.

[...]

J'imagine qu'un char* aurait eu exactement le format d'un « byte
pointer ».

Je ne vois pas comment faire autrement de manière pratique.

Note que si je comprends la documentation à la site
ci-dessus correctement, la position était bien sur les
poids faibles du mot. Or, je me rappelle bien avoir parlé
avec quelqu'un qui m'a racconté d'une architecture à peu
près semblable, mais avec la position aux poids forts. De
façon que quand tu incrémentais un pointeur de byte la
première fois, c'était bien dans les poids forts où
l'incrémentation avait lieu, et que (unsigned)p >
(unsigned)(p+1).

Quand je lis:

A byte pointer has the following format:

000000 000011 1 1 1111 112222222222333333
012345 678901 2 3 4567 890123456789012345
_________________________________________
| | | | | | |
| POS | SIZE |U|I| X | Y |
|______|______|_|_|____|__________________|

POS is the byte position: the number of bits from the right
end of the byte to the right end of the word.

Je comprends que la position se trouve bien dans les bits de
poids forts (le PDP-10 est grand boutien dans sa
numérotation des bits). Le contraire aurait contredit mes
souvenirs.

|> Vous pensez que c'est compliqué? Je n'ai pas abordé le
|> sujet de l'adressage étendu (dont je n'ai que des
|> vagues souvenirs) permettant des adresses sur plus de
|> 18 bits.

Il y en avait sur les PDP-10 aussi.

C'est ce que je dis. Mais je ne suis plus capable de
décrire comment ça fonctionnait, en particulier pour les
pointeurs de byte.

Je m'en souviens bien sur les PDP-11 (et sur prèsque
toutes les machines de 16 bits).

Mais en fait, les IA-32 ont encore quelque chose de
semblable, qui sert pour permettre des adresses de plus de
32 bits. Et même si Windows et Linux préfère en ignorer
l'existance, je m'en suis déjà servi.

Jamais utilisé ça, mais j'avais cru comprendre que c'était
simplement le mapping adresse virtuelle -> adresse physique
qui permettait d'avoir plus de 32 bits d'adresse physique et
que l'espace mémoire virtuel était bien limité à 32 bits.

Sur les premiers PDP-10, l'espace mémoire virtuel était de
18 bits. Sur les derniers, l'espace mémoire virtuel était
plus large (j'ai le vague souvenir de 30 bits) avec de la
segmentation et de calcul d'adresse différent suivant le
segment dans lequel on était.

[...]

En fait, on pourrait dire que sur un IBM 1401, les chars
équivalaient au mot. Mais seulement parce que le seul «
mot » sur ces machines n'avait que six (ou sept, ou huit,
selon ce que tu comptais) bits. Les « nombres » sur la
machine était décimaux, normalement non-packé, sur une
suite de « mots », avec un flag de fin. Il n'y avait aucun
arithmétique binaire.

Je ne connaissais pas. C'est ce genre de machines qu'on
appelait des machines commerciales (opposées aux machines
scientifiques)?

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Vous avez filtré cet utilisateur ! Consultez son message

James Kanze writes:

(Je me suis trompé en fait sur la taille. C'était 36 bits,
évidemment. Mais quelle était alors la machine à 24
bits?)

Je n'en sais rien. Il me semble que Digital en a fait.

|> (Toujours de mémoire, donc sujet à erreur, et je
|> répète que je n'ai pas programmé cette machine en C,
|> donc ça diminue d'autant la qualité de mes souvenirs
|> sur le C)

Moi, je n'en ai même jamais eu sous la main. Mes souvenirs
ne concernent que ce que l'ai lu. Il y a peu de temps,
d'ailleurs.

C'est le premier ordinateur sur lequel j'ai eu des cours.
L'année d'après j'ai changé d'unif et là c'était sur VAX.

[...]

J'imagine qu'un char* aurait eu exactement le format d'un « byte
pointer ».

Je ne vois pas comment faire autrement de manière pratique.

Note que si je comprends la documentation à la site
ci-dessus correctement, la position était bien sur les
poids faibles du mot. Or, je me rappelle bien avoir parlé
avec quelqu'un qui m'a racconté d'une architecture à peu
près semblable, mais avec la position aux poids forts. De
façon que quand tu incrémentais un pointeur de byte la
première fois, c'était bien dans les poids forts où
l'incrémentation avait lieu, et que (unsigned)p >
(unsigned)(p+1).

Quand je lis:

A byte pointer has the following format:

000000 000011 1 1 1111 112222222222333333
012345 678901 2 3 4567 890123456789012345
_________________________________________
| | | | | | |
| POS | SIZE |U|I| X | Y |
|______|______|_|_|____|__________________|

POS is the byte position: the number of bits from the right
end of the byte to the right end of the word.

Je comprends que la position se trouve bien dans les bits de
poids forts (le PDP-10 est grand boutien dans sa
numérotation des bits). Le contraire aurait contredit mes
souvenirs.

|> Vous pensez que c'est compliqué? Je n'ai pas abordé le
|> sujet de l'adressage étendu (dont je n'ai que des
|> vagues souvenirs) permettant des adresses sur plus de
|> 18 bits.

Il y en avait sur les PDP-10 aussi.

C'est ce que je dis. Mais je ne suis plus capable de
décrire comment ça fonctionnait, en particulier pour les
pointeurs de byte.

Je m'en souviens bien sur les PDP-11 (et sur prèsque
toutes les machines de 16 bits).

Mais en fait, les IA-32 ont encore quelque chose de
semblable, qui sert pour permettre des adresses de plus de
32 bits. Et même si Windows et Linux préfère en ignorer
l'existance, je m'en suis déjà servi.

Jamais utilisé ça, mais j'avais cru comprendre que c'était
simplement le mapping adresse virtuelle -> adresse physique
qui permettait d'avoir plus de 32 bits d'adresse physique et
que l'espace mémoire virtuel était bien limité à 32 bits.

Sur les premiers PDP-10, l'espace mémoire virtuel était de
18 bits. Sur les derniers, l'espace mémoire virtuel était
plus large (j'ai le vague souvenir de 30 bits) avec de la
segmentation et de calcul d'adresse différent suivant le
segment dans lequel on était.

[...]

En fait, on pourrait dire que sur un IBM 1401, les chars
équivalaient au mot. Mais seulement parce que le seul «
mot » sur ces machines n'avait que six (ou sept, ou huit,
selon ce que tu comptais) bits. Les « nombres » sur la
machine était décimaux, normalement non-packé, sur une
suite de « mots », avec un flag de fin. Il n'y avait aucun
arithmétique binaire.

Je ne connaissais pas. C'est ce genre de machines qu'on
appelait des machines commerciales (opposées aux machines
scientifiques)?

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Jean-Marc Bourguet

23/10/2004 à 19:50

James Kanze writes:

À peu près. Mais apparamment, la possibilité d'extraire un champs de
bits (indépendamment de son utilisation pour des chars) était assez
intéressante pour qu'ils l'implémentent aussi sur la VAX.

Avec la réputation qu'a le VAX, ça ne m'étonne pas. Surtout
qu'à l'époque où il a été conçu on comptait la mémoire.

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

James Kanze

24/10/2004 à 23:13

Jean-Marc Bourguet writes:

|> James Kanze writes:

[...]
|> A byte pointer has the following format:

|> 000000 000011 1 1 1111 112222222222333333
|> 012345 678901 2 3 4567 890123456789012345
|> _________________________________________
|> | | | | | | |
|> | POS | SIZE |U|I| X | Y |
|> |______|______|_|_|____|__________________|

|> POS is the byte position: the number of bits from the right end of
|> the byte to the right end of the word.

|> Je comprends que la position se trouve bien dans les bits de poids
|> forts (le PDP-10 est grand boutien dans sa numérotation des bits).

C'est le fait que le PDP-10 est grand boutien dans la numérotation des
bits qui me manquait. En fait, je croyais qu'il n'y avait que IBM pour
faire ce genre de bêtise. (Et chez IBM, c'est évident que quelque chose
cloche, parce qu'il commence la numérotation par 1, et non 0.)

[...]
|> > Mais en fait, les IA-32 ont encore quelque chose de semblable, qui
|> > sert pour permettre des adresses de plus de 32 bits. Et même si
|> > Windows et Linux préfère en ignorer l'existance, je m'en suis déjà
|> > servi.

|> Jamais utilisé ça, mais j'avais cru comprendre que c'était
|> simplement le mapping adresse virtuelle -> adresse physique
|> qui permettait d'avoir plus de 32 bits d'adresse physique et
|> que l'espace mémoire virtuel était bien limité à 32 bits.

D'après mes souvenirs, il y avait un bit de sélection dans un mot du
descripteur de sélecteur qui jouait là-dessus, et qu'il y avait bien une
option qui permettait 48 bits d'adresses dans la mémoire virtuelle. Mais
j'avoue que ce n'est que des souvenirs, qui datent en plus, étant donné
que je n'ai plus travaillé sur Intel depuis 1988.

|> [...]
|> > En fait, on pourrait dire que sur un IBM 1401, les chars
|> > équivalaient au mot. Mais seulement parce que le seul « mot » sur
|> > ces machines n'avait que six (ou sept, ou huit, selon ce que tu
|> > comptais) bits. Les « nombres » sur la machine était décimaux,
|> > normalement non-packé, sur une suite de « mots », avec un flag de
|> > fin. Il n'y avait aucun arithmétique binaire.

|> Je ne connaissais pas. C'est ce genre de machines qu'on appelait des
|> machines commerciales (opposées aux machines scientifiques)?

Je crois. J'avoue que je ne l'ai connu que par hazard. La boîte où
travaillait mon père en avait acheté un, et lui devait suivre un cours
de soir pour le programmer. J'étais curieux, et il a obtenu
l'autorisation que je suis le cours aussi. Du coup, j'ai écrit mes
premiers programmes en 1964, à l'âge de 16 ans.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Jean-Marc Bourguet <jm@bourguet.org> writes:

|> James Kanze <james.kanze@free.fr> writes:

[...]
|> A byte pointer has the following format:

|> 000000 000011 1 1 1111 112222222222333333
|> 012345 678901 2 3 4567 890123456789012345
|> _________________________________________
|> | | | | | | |
|> | POS | SIZE |U|I| X | Y |
|> |______|______|_|_|____|__________________|

|> POS is the byte position: the number of bits from the right end of
|> the byte to the right end of the word.

|> Je comprends que la position se trouve bien dans les bits de poids
|> forts (le PDP-10 est grand boutien dans sa numérotation des bits).

C'est le fait que le PDP-10 est grand boutien dans la numérotation des
bits qui me manquait. En fait, je croyais qu'il n'y avait que IBM pour
faire ce genre de bêtise. (Et chez IBM, c'est évident que quelque chose
cloche, parce qu'il commence la numérotation par 1, et non 0.)

[...]
|> > Mais en fait, les IA-32 ont encore quelque chose de semblable, qui
|> > sert pour permettre des adresses de plus de 32 bits. Et même si
|> > Windows et Linux préfère en ignorer l'existance, je m'en suis déjà
|> > servi.

|> Jamais utilisé ça, mais j'avais cru comprendre que c'était
|> simplement le mapping adresse virtuelle -> adresse physique
|> qui permettait d'avoir plus de 32 bits d'adresse physique et
|> que l'espace mémoire virtuel était bien limité à 32 bits.

D'après mes souvenirs, il y avait un bit de sélection dans un mot du
descripteur de sélecteur qui jouait là-dessus, et qu'il y avait bien une
option qui permettait 48 bits d'adresses dans la mémoire virtuelle. Mais
j'avoue que ce n'est que des souvenirs, qui datent en plus, étant donné
que je n'ai plus travaillé sur Intel depuis 1988.

|> [...]
|> > En fait, on pourrait dire que sur un IBM 1401, les chars
|> > équivalaient au mot. Mais seulement parce que le seul « mot » sur
|> > ces machines n'avait que six (ou sept, ou huit, selon ce que tu
|> > comptais) bits. Les « nombres » sur la machine était décimaux,
|> > normalement non-packé, sur une suite de « mots », avec un flag de
|> > fin. Il n'y avait aucun arithmétique binaire.

|> Je ne connaissais pas. C'est ce genre de machines qu'on appelait des
|> machines commerciales (opposées aux machines scientifiques)?

Je crois. J'avoue que je ne l'ai connu que par hazard. La boîte où
travaillait mon père en avait acheté un, et lui devait suivre un cours
de soir pour le programmer. J'étais curieux, et il a obtenu
l'autorisation que je suis le cours aussi. Du coup, j'ai écrit mes
premiers programmes en 1964, à l'âge de 16 ans.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Vous avez filtré cet utilisateur ! Consultez son message

Jean-Marc Bourguet writes:

|> James Kanze writes:

[...]
|> A byte pointer has the following format:

|> 000000 000011 1 1 1111 112222222222333333
|> 012345 678901 2 3 4567 890123456789012345
|> _________________________________________
|> | | | | | | |
|> | POS | SIZE |U|I| X | Y |
|> |______|______|_|_|____|__________________|

|> POS is the byte position: the number of bits from the right end of
|> the byte to the right end of the word.

|> Je comprends que la position se trouve bien dans les bits de poids
|> forts (le PDP-10 est grand boutien dans sa numérotation des bits).

C'est le fait que le PDP-10 est grand boutien dans la numérotation des
bits qui me manquait. En fait, je croyais qu'il n'y avait que IBM pour
faire ce genre de bêtise. (Et chez IBM, c'est évident que quelque chose
cloche, parce qu'il commence la numérotation par 1, et non 0.)

[...]
|> > Mais en fait, les IA-32 ont encore quelque chose de semblable, qui
|> > sert pour permettre des adresses de plus de 32 bits. Et même si
|> > Windows et Linux préfère en ignorer l'existance, je m'en suis déjà
|> > servi.

|> Jamais utilisé ça, mais j'avais cru comprendre que c'était
|> simplement le mapping adresse virtuelle -> adresse physique
|> qui permettait d'avoir plus de 32 bits d'adresse physique et
|> que l'espace mémoire virtuel était bien limité à 32 bits.

D'après mes souvenirs, il y avait un bit de sélection dans un mot du
descripteur de sélecteur qui jouait là-dessus, et qu'il y avait bien une
option qui permettait 48 bits d'adresses dans la mémoire virtuelle. Mais
j'avoue que ce n'est que des souvenirs, qui datent en plus, étant donné
que je n'ai plus travaillé sur Intel depuis 1988.

|> [...]
|> > En fait, on pourrait dire que sur un IBM 1401, les chars
|> > équivalaient au mot. Mais seulement parce que le seul « mot » sur
|> > ces machines n'avait que six (ou sept, ou huit, selon ce que tu
|> > comptais) bits. Les « nombres » sur la machine était décimaux,
|> > normalement non-packé, sur une suite de « mots », avec un flag de
|> > fin. Il n'y avait aucun arithmétique binaire.

|> Je ne connaissais pas. C'est ce genre de machines qu'on appelait des
|> machines commerciales (opposées aux machines scientifiques)?

Je crois. J'avoue que je ne l'ai connu que par hazard. La boîte où
travaillait mon père en avait acheté un, et lui devait suivre un cours
de soir pour le programmer. J'étais curieux, et il a obtenu
l'autorisation que je suis le cours aussi. Du coup, j'ai écrit mes
premiers programmes en 1964, à l'âge de 16 ans.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Thierry Boudet

25/10/2004 à 00:05

On 2004-10-22, Emmanuel Delahaye wrote:

Désolé, mais je n'arrive jamais à me souvenir du sens de big/little endian.
Alors je parle en opposition Intel/Motorola...

Bienvenu au club! Si quelqu'un a un moyen mnémotechnique, qu'il le
dise!

Peut-être en fouillant là :)

http://catb.org/~esr/jargon/html/N/NUXI-problem.html

--
_/°< coin

Gabriel Dos Reis

25/10/2004 à 03:35

James Kanze writes:

| (Et chez IBM, c'est évident que quelque chose
| cloche, parce qu'il commence la numérotation par 1, et non 0.)

Peut-être qu'à l'époque leurs ingénieurs avaient une bonne dose
d'éducation mathématique et ils savaient faire la différence entre
position et cardinal ;-p

-- Gaby

Jean-Marc Bourguet

25/10/2004 à 10:41

James Kanze writes:

|> Jamais utilisé ça, mais j'avais cru comprendre que c'était
|> simplement le mapping adresse virtuelle -> adresse physique
|> qui permettait d'avoir plus de 32 bits d'adresse physique et
|> que l'espace mémoire virtuel était bien limité à 32 bits.

D'après mes souvenirs, il y avait un bit de sélection dans un mot du
descripteur de sélecteur qui jouait là-dessus, et qu'il y avait bien
une option qui permettait 48 bits d'adresses dans la mémoire
virtuelle. Mais j'avoue que ce n'est que des souvenirs, qui datent
en plus, étant donné que je n'ai plus travaillé sur Intel depuis
1988.

A cette epoque je suis quasiment certain que la transformation etait
1/ adresse segmentee (46 bits significatifs, 2 des bits du segment
etaient des info de protection) -> adresse paginee sur 32 bits
2/ adresse paginee sur 32 bits -> adresse physique sur 32 bits

Posterieurement au 486 (et vraissemblablement au premier Pentium), il
me semble que la deuxieme phase peut generer une adresse physique de
plus de 32 bits. C'est a quoi je faisais allusion.

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Marc Boyer

25/10/2004 à 10:45

James Kanze wrote:

Pierre Maurette writes:
|> De même pour le DWORD 0x12345678, écrit comme un DWORD:
|> little endian: 78 56 34 12
|> big endian: 12 34 56 78

Ou 56 78 12 34, comme c'était le cas sur certains processeurs ou avec
certains compilateurs (sur 8086, par exemple).

Il me semblait bien qu'il y avait un truc dans le genre,
et que le monde ne se divisait pas juste en little vs big.

Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.

Gabriel Dos Reis

25/10/2004 à 11:39

big/little endian

10 réponses

Veuillez sélectionner un problème