Est-il possible avoir un code en C capable de detecter le type de
processeur, en de lui forcer l'ecriture ou la lecture d'un fichier
binnaire en little ou big endian indifferement ???
C'est pas pire qu'un architecture avec des int qui font 32 bits au lieu des 16 requis. Les 16 bits de poids forts ne doivent pas être utilisés si on veut écrire du code portable. C'est tout.
Le C, c'est simple :
8 bits -> char 16 bits -> int ou short 32 bits -> long [C99] 64 bits -> long long
Serais-tu en train de citer la norme ? laquelle ? Pourrais-je connaitre le(s) paragraphe(s) en question ?
Ce sont des minimas. 5.2.4.2.1.
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
"Emmanuel Delahaye" <emdel@YOURBRAnoos.fr> a écrit
C'est pas pire qu'un architecture avec des int qui font 32 bits au lieu
des 16 requis. Les 16 bits de poids forts ne doivent pas être utilisés
si on veut écrire du code portable. C'est tout.
Le C, c'est simple :
8 bits -> char
16 bits -> int ou short
32 bits -> long
[C99]
64 bits -> long long
Serais-tu en train de citer la norme ? laquelle ? Pourrais-je connaitre
le(s) paragraphe(s) en question ?
Ce sont des minimas. 5.2.4.2.1.
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
C'est pas pire qu'un architecture avec des int qui font 32 bits au lieu des 16 requis. Les 16 bits de poids forts ne doivent pas être utilisés si on veut écrire du code portable. C'est tout.
Le C, c'est simple :
8 bits -> char 16 bits -> int ou short 32 bits -> long [C99] 64 bits -> long long
Serais-tu en train de citer la norme ? laquelle ? Pourrais-je connaitre le(s) paragraphe(s) en question ?
Ce sont des minimas. 5.2.4.2.1.
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
K. Ahausse
"Emmanuel Delahaye" a écrit
C'est pas pire qu'un architecture avec des int qui font 32 bits au lieu des 16 requis. Les 16 bits de poids forts ne doivent pas être utilisés si on veut écrire du code portable. C'est tout.
Le C, c'est simple :
8 bits -> char 16 bits -> int ou short 32 bits -> long [C99] 64 bits -> long long
Serais-tu en train de citer la norme ? laquelle ? Pourrais-je connaitre le(s) paragraphe(s) en question ?
"Emmanuel Delahaye" <emdel@YOURBRAnoos.fr> a écrit
C'est pas pire qu'un architecture avec des int qui font 32 bits au lieu
des 16 requis. Les 16 bits de poids forts ne doivent pas être utilisés
si on veut écrire du code portable. C'est tout.
Le C, c'est simple :
8 bits -> char
16 bits -> int ou short
32 bits -> long
[C99]
64 bits -> long long
Serais-tu en train de citer la norme ? laquelle ? Pourrais-je connaitre
le(s) paragraphe(s) en question ?
C'est pas pire qu'un architecture avec des int qui font 32 bits au lieu des 16 requis. Les 16 bits de poids forts ne doivent pas être utilisés si on veut écrire du code portable. C'est tout.
Le C, c'est simple :
8 bits -> char 16 bits -> int ou short 32 bits -> long [C99] 64 bits -> long long
Serais-tu en train de citer la norme ? laquelle ? Pourrais-je connaitre le(s) paragraphe(s) en question ?
Jean-Marc Bourguet
Gabriel Dos Reis writes:
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
« Many mathematicians prefer to count objects starting at "zero" rather than "one." Although this may be unfamiliar, it is really a much simpler method. » J.H. Conway
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
Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
James Kanze <james.kanze@free.fr> 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
« Many mathematicians prefer to count objects starting at
"zero" rather than "one." Although this may be unfamiliar,
it is really a much simpler method. »
J.H. Conway
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
| (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
« Many mathematicians prefer to count objects starting at "zero" rather than "one." Although this may be unfamiliar, it is really a much simpler method. » J.H. Conway
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
Emmanuel Delahaye
K. Ahausse wrote on 25/10/04 :
"Emmanuel Delahaye" a écrit
C'est pas pire qu'un architecture avec des int qui font 32 bits au lieu des 16 requis. Les 16 bits de poids forts ne doivent pas être utilisés si on veut écrire du code portable. C'est tout.
Le C, c'est simple :
8 bits -> char 16 bits -> int ou short 32 bits -> long [C99] 64 bits -> long long
Serais-tu en train de citer la norme ? laquelle ? Pourrais-je connaitre le(s) paragraphe(s) en question ?
ISO/IEC 9899:1999 (E) 5.2.4.2 Numerical limits
La norme donne des valeurs minimales pour ces types qui se traduisent par un certain nombre de bits minimums. Utiliser les bits supplémentaires rend le programme non portable.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
K. Ahausse wrote on 25/10/04 :
"Emmanuel Delahaye" <emdel@YOURBRAnoos.fr> a écrit
C'est pas pire qu'un architecture avec des int qui font 32 bits au lieu
des 16 requis. Les 16 bits de poids forts ne doivent pas être utilisés
si on veut écrire du code portable. C'est tout.
Le C, c'est simple :
8 bits -> char
16 bits -> int ou short
32 bits -> long
[C99]
64 bits -> long long
Serais-tu en train de citer la norme ? laquelle ? Pourrais-je connaitre
le(s) paragraphe(s) en question ?
ISO/IEC 9899:1999 (E)
5.2.4.2 Numerical limits
La norme donne des valeurs minimales pour ces types qui se traduisent
par un certain nombre de bits minimums. Utiliser les bits
supplémentaires rend le programme non portable.
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
C'est pas pire qu'un architecture avec des int qui font 32 bits au lieu des 16 requis. Les 16 bits de poids forts ne doivent pas être utilisés si on veut écrire du code portable. C'est tout.
Le C, c'est simple :
8 bits -> char 16 bits -> int ou short 32 bits -> long [C99] 64 bits -> long long
Serais-tu en train de citer la norme ? laquelle ? Pourrais-je connaitre le(s) paragraphe(s) en question ?
ISO/IEC 9899:1999 (E) 5.2.4.2 Numerical limits
La norme donne des valeurs minimales pour ces types qui se traduisent par un certain nombre de bits minimums. Utiliser les bits supplémentaires rend le programme non portable.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
James Kanze
Gabriel Dos Reis writes:
|> Marc Boyer writes:
|> | 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.
|> oui, il y a aussi les mid ;-) |> (PDP-family, VAX, ...)
Ce sont des little big endian, ou les big little endian, selon que la nomenclature est big endian ou little endian.
-- 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
Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
|> Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
|> | James Kanze wrote:
|> | > Pierre Maurette <maurettepierre@wanadoo.fr> 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.
|> oui, il y a aussi les mid ;-)
|> (PDP-family, VAX, ...)
Ce sont des little big endian, ou les big little endian, selon que la
nomenclature est big endian ou little endian.
--
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 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.
|> oui, il y a aussi les mid ;-) |> (PDP-family, VAX, ...)
Ce sont des little big endian, ou les big little endian, selon que la nomenclature est big endian ou little endian.
-- 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
Antoine Leca
En , Gabriel Dos Reis va escriure:
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.
oui, il y a aussi les mid ;-) (PDP-family, VAX, ...)
Les Vax sont des petit-boutiens parfaitement semblables à IA32. C'est d'ailleurs logique pour un processeur capable de manipuler des données de taille variable: l'adresse n'est pas dépendante de la taille de la donnée.
Le cas des PDP-11 est plus complexe: en fait les PDP-11 sont eux aussi des petit-boutiens, mais eux sont parfaitement semblables à IA-16 (8086-80286), car ce sont des machines 16 bits.
Avec certains OS (ceux de DEC), les éventuelles valeurs 32 bits (toujours manipulées comme deux mots de 16 bits) sont stockées en ordre petit boutien aussi, toujours tout normal.
Mais avec « l'autre OS », et ses dérivés, les routines de biblithèques qui ont été écrites (en 1975 ± 1 an) pour avoir des opérations sur 32 bits (qui se sont appelés time_t et off_t par la suite) ont été écrites sans tenir compte du matériel, donc les programmeurs ont choisi l'ordre (pour les deux mots 16 bits entre eux) qui leur paraissait logique à eux humains, gros-boutien. Et quand on regarde avec la loupe du débogueur, le résultat est le cauchemard 3412 ou 2143, comme vous préférez.
Il y a des trucs du même genre dans le BIOS du PC IBM ou MS-DOS (je crois que la date-heure de la FAT est de ce genre-là, pas certain), mais cela n'a pas eu le même succès littéraire...
Antoine
En m3hdojkufx.fsf@merlin.cs.tamu.edu, Gabriel Dos Reis va escriure:
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.
oui, il y a aussi les mid ;-)
(PDP-family, VAX, ...)
Les Vax sont des petit-boutiens parfaitement semblables à IA32. C'est
d'ailleurs logique pour un processeur capable de manipuler des données de
taille variable: l'adresse n'est pas dépendante de la taille de la donnée.
Le cas des PDP-11 est plus complexe: en fait les PDP-11 sont eux aussi des
petit-boutiens, mais eux sont parfaitement semblables à IA-16 (8086-80286),
car ce sont des machines 16 bits.
Avec certains OS (ceux de DEC), les éventuelles valeurs 32 bits (toujours
manipulées comme deux mots de 16 bits) sont stockées en ordre petit boutien
aussi, toujours tout normal.
Mais avec « l'autre OS », et ses dérivés, les routines de biblithèques qui
ont été écrites (en 1975 ± 1 an) pour avoir des opérations sur 32 bits (qui
se sont appelés time_t et off_t par la suite) ont été écrites sans tenir
compte du matériel, donc les programmeurs ont choisi l'ordre (pour les deux
mots 16 bits entre eux) qui leur paraissait logique à eux humains,
gros-boutien. Et quand on regarde avec la loupe du débogueur, le résultat
est le cauchemard 3412 ou 2143, comme vous préférez.
Il y a des trucs du même genre dans le BIOS du PC IBM ou MS-DOS (je crois
que la date-heure de la FAT est de ce genre-là, pas certain), mais cela n'a
pas eu le même succès littéraire...
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.
oui, il y a aussi les mid ;-) (PDP-family, VAX, ...)
Les Vax sont des petit-boutiens parfaitement semblables à IA32. C'est d'ailleurs logique pour un processeur capable de manipuler des données de taille variable: l'adresse n'est pas dépendante de la taille de la donnée.
Le cas des PDP-11 est plus complexe: en fait les PDP-11 sont eux aussi des petit-boutiens, mais eux sont parfaitement semblables à IA-16 (8086-80286), car ce sont des machines 16 bits.
Avec certains OS (ceux de DEC), les éventuelles valeurs 32 bits (toujours manipulées comme deux mots de 16 bits) sont stockées en ordre petit boutien aussi, toujours tout normal.
Mais avec « l'autre OS », et ses dérivés, les routines de biblithèques qui ont été écrites (en 1975 ± 1 an) pour avoir des opérations sur 32 bits (qui se sont appelés time_t et off_t par la suite) ont été écrites sans tenir compte du matériel, donc les programmeurs ont choisi l'ordre (pour les deux mots 16 bits entre eux) qui leur paraissait logique à eux humains, gros-boutien. Et quand on regarde avec la loupe du débogueur, le résultat est le cauchemard 3412 ou 2143, comme vous préférez.
Il y a des trucs du même genre dans le BIOS du PC IBM ou MS-DOS (je crois que la date-heure de la FAT est de ce genre-là, pas certain), mais cela n'a pas eu le même succès littéraire...
Antoine
James Kanze
"Antoine Leca" writes:
[...] |> Mais avec « l'autre OS », et ses dérivés, les routines de |> biblithèques qui ont été écrites (en 1975 ± 1 an) pour avoir des |> opérations sur 32 bits (qui se sont appelés time_t et off_t par la |> suite) ont été écrites sans tenir compte du matériel, donc les |> programmeurs ont choisi l'ordre (pour les deux mots 16 bits entre |> eux) qui leur paraissait logique à eux humains, gros-boutien. Et |> quand on regarde avec la loupe du débogueur, le résultat est le |> cauchemard 3412 ou 2143, comme vous préférez.
|> Il y a des trucs du même genre dans le BIOS du PC IBM ou MS-DOS (je |> crois que la date-heure de la FAT est de ce genre-là, pas certain), |> mais cela n'a pas eu le même succès littéraire...
C'est comme ça que fonctionnait le compilateur Microsoft. Jusqu'à un certain époque. Le résultat : on a la représentation des longs qui a changé d'une version à l'autre du compilateur.
-- 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
"Antoine Leca" <root@localhost.gov> writes:
[...]
|> Mais avec « l'autre OS », et ses dérivés, les routines de
|> biblithèques qui ont été écrites (en 1975 ± 1 an) pour avoir des
|> opérations sur 32 bits (qui se sont appelés time_t et off_t par la
|> suite) ont été écrites sans tenir compte du matériel, donc les
|> programmeurs ont choisi l'ordre (pour les deux mots 16 bits entre
|> eux) qui leur paraissait logique à eux humains, gros-boutien. Et
|> quand on regarde avec la loupe du débogueur, le résultat est le
|> cauchemard 3412 ou 2143, comme vous préférez.
|> Il y a des trucs du même genre dans le BIOS du PC IBM ou MS-DOS (je
|> crois que la date-heure de la FAT est de ce genre-là, pas certain),
|> mais cela n'a pas eu le même succès littéraire...
C'est comme ça que fonctionnait le compilateur Microsoft. Jusqu'à un
certain époque. Le résultat : on a la représentation des longs qui a
changé d'une version à l'autre du compilateur.
--
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
[...] |> Mais avec « l'autre OS », et ses dérivés, les routines de |> biblithèques qui ont été écrites (en 1975 ± 1 an) pour avoir des |> opérations sur 32 bits (qui se sont appelés time_t et off_t par la |> suite) ont été écrites sans tenir compte du matériel, donc les |> programmeurs ont choisi l'ordre (pour les deux mots 16 bits entre |> eux) qui leur paraissait logique à eux humains, gros-boutien. Et |> quand on regarde avec la loupe du débogueur, le résultat est le |> cauchemard 3412 ou 2143, comme vous préférez.
|> Il y a des trucs du même genre dans le BIOS du PC IBM ou MS-DOS (je |> crois que la date-heure de la FAT est de ce genre-là, pas certain), |> mais cela n'a pas eu le même succès littéraire...
C'est comme ça que fonctionnait le compilateur Microsoft. Jusqu'à un certain époque. Le résultat : on a la représentation des longs qui a changé d'une version à l'autre du compilateur.
-- 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
Gabriel Dos Reis
James Kanze writes:
| Gabriel Dos Reis writes: | | |> Marc Boyer writes: | | |> | 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. | | |> oui, il y a aussi les mid ;-) | |> (PDP-family, VAX, ...) | | Ce sont des little big endian, ou les big little endian, selon que la | nomenclature est big endian ou little endian.
La suggestion « mid » était une blague entre « little » et « big » et non quelque chose de sérieux de ma part. J'aurais dû mettre un smiley ;-p
-- Gaby
James Kanze <james.kanze@free.fr> writes:
| Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
|
| |> Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
|
| |> | James Kanze wrote:
| |> | > Pierre Maurette <maurettepierre@wanadoo.fr> 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.
|
| |> oui, il y a aussi les mid ;-)
| |> (PDP-family, VAX, ...)
|
| Ce sont des little big endian, ou les big little endian, selon que la
| nomenclature est big endian ou little endian.
La suggestion « mid » était une blague entre « little » et « big »
et non quelque chose de sérieux de ma part. J'aurais dû mettre un smiley ;-p
| Gabriel Dos Reis writes: | | |> Marc Boyer writes: | | |> | 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. | | |> oui, il y a aussi les mid ;-) | |> (PDP-family, VAX, ...) | | Ce sont des little big endian, ou les big little endian, selon que la | nomenclature est big endian ou little endian.
La suggestion « mid » était une blague entre « little » et « big » et non quelque chose de sérieux de ma part. J'aurais dû mettre un smiley ;-p
-- Gaby
Pierre Maurette
Gabriel Dos Reis a écrit: [...]
La suggestion « mid » était une blague entre « little » et « big » et non quelque chose de sérieux de ma part. J'aurais dû mettre un smiley ;-p Pourtant,
http://membres.lycos.fr/cgiguere/vdn/vdn71/vdn71.htm -- Pierre
Gabriel Dos Reis <gdr@cs.tamu.edu> a écrit:
[...]
La suggestion « mid » était une blague entre « little » et « big »
et non quelque chose de sérieux de ma part. J'aurais dû mettre un smiley ;-p
Pourtant,
http://membres.lycos.fr/cgiguere/vdn/vdn71/vdn71.htm
--
Pierre
La suggestion « mid » était une blague entre « little » et « big » et non quelque chose de sérieux de ma part. J'aurais dû mettre un smiley ;-p Pourtant,
http://membres.lycos.fr/cgiguere/vdn/vdn71/vdn71.htm -- Pierre
Antoine Leca
En , James Kanze va escriure:
Il y a des trucs du même genre dans le BIOS du PC IBM ou MS-DOS (je crois que la date-heure de la FAT est de ce genre-là, pas certain), mais cela n'a pas eu le même succès littéraire...
C'est comme ça que fonctionnait le compilateur Microsoft. Jusqu'à un certain époque. Le résultat : on a la représentation des longs qui a changé d'une version à l'autre du compilateur.
???
Tu parles bien de celui de Microsoft, donc à partir de la 4 (1986) et après ? Je n'ai jamais vu quoi que ce soit d'approchant...
Avant la 4, le compilo de M$ était celui de Lattice, et là, je n'ai pas tous les éléments pour décider, je ne jouais pas avec ce truc-là, trop cher pour un étudiant. J'ai juste la v.2 dans un coin, et je n'avais pas l'impression qu'il était spécifique par rapport aux autres (celui d'Intel ou celui de CI). Mais je n'ai pas regardé de près (et je ne l'ai pas sous la main pour vérifier).
Un truc ressemblant de l'époque, par contre, c'est que les _listings_ (pas les binaires) de l'assembleur d'Intel écrivait les quantités 16 bits comme ils sont dans le binaire, tandis que celui de Microsoft les écrivait de manière lisible pour les humains. Donc on obtenait asm86: A03412 mov AL, DS:[BYTE PTR 1234h] masm: A0 1234 mov AL, DS:[BYTE PTR 1234h]
Et le fameux listing du BIOS du PC (que tout le monde a pompé sans vergogne et qui a donné son élan à l'industrie des PC) est imprimé avec l'assembleur d'Intel, tandis que « tout le monde » utilise celui de Microsoft, donc cela a créé des confusions.
Antoine
En m2fz40rm9i.fsf@thomas.gabi-soft.fr, James Kanze va escriure:
Il y a des trucs du même genre dans le BIOS du PC IBM ou MS-DOS (je
crois que la date-heure de la FAT est de ce genre-là, pas certain),
mais cela n'a pas eu le même succès littéraire...
C'est comme ça que fonctionnait le compilateur Microsoft. Jusqu'à un
certain époque. Le résultat : on a la représentation des longs qui a
changé d'une version à l'autre du compilateur.
???
Tu parles bien de celui de Microsoft, donc à partir de la 4 (1986) et après
? Je n'ai jamais vu quoi que ce soit d'approchant...
Avant la 4, le compilo de M$ était celui de Lattice, et là, je n'ai pas tous
les éléments pour décider, je ne jouais pas avec ce truc-là, trop cher pour
un étudiant. J'ai juste la v.2 dans un coin, et je n'avais pas l'impression
qu'il était spécifique par rapport aux autres (celui d'Intel ou celui de
CI). Mais je n'ai pas regardé de près (et je ne l'ai pas sous la main pour
vérifier).
Un truc ressemblant de l'époque, par contre, c'est que les _listings_ (pas
les binaires) de l'assembleur d'Intel écrivait les quantités 16 bits comme
ils sont dans le binaire, tandis que celui de Microsoft les écrivait de
manière lisible pour les humains. Donc on obtenait
asm86:
A03412 mov AL, DS:[BYTE PTR 1234h]
masm:
A0 1234 mov AL, DS:[BYTE PTR 1234h]
Et le fameux listing du BIOS du PC (que tout le monde a pompé sans vergogne
et qui a donné son élan à l'industrie des PC) est imprimé avec l'assembleur
d'Intel, tandis que « tout le monde » utilise celui de Microsoft, donc cela
a créé des confusions.
Il y a des trucs du même genre dans le BIOS du PC IBM ou MS-DOS (je crois que la date-heure de la FAT est de ce genre-là, pas certain), mais cela n'a pas eu le même succès littéraire...
C'est comme ça que fonctionnait le compilateur Microsoft. Jusqu'à un certain époque. Le résultat : on a la représentation des longs qui a changé d'une version à l'autre du compilateur.
???
Tu parles bien de celui de Microsoft, donc à partir de la 4 (1986) et après ? Je n'ai jamais vu quoi que ce soit d'approchant...
Avant la 4, le compilo de M$ était celui de Lattice, et là, je n'ai pas tous les éléments pour décider, je ne jouais pas avec ce truc-là, trop cher pour un étudiant. J'ai juste la v.2 dans un coin, et je n'avais pas l'impression qu'il était spécifique par rapport aux autres (celui d'Intel ou celui de CI). Mais je n'ai pas regardé de près (et je ne l'ai pas sous la main pour vérifier).
Un truc ressemblant de l'époque, par contre, c'est que les _listings_ (pas les binaires) de l'assembleur d'Intel écrivait les quantités 16 bits comme ils sont dans le binaire, tandis que celui de Microsoft les écrivait de manière lisible pour les humains. Donc on obtenait asm86: A03412 mov AL, DS:[BYTE PTR 1234h] masm: A0 1234 mov AL, DS:[BYTE PTR 1234h]
Et le fameux listing du BIOS du PC (que tout le monde a pompé sans vergogne et qui a donné son élan à l'industrie des PC) est imprimé avec l'assembleur d'Intel, tandis que « tout le monde » utilise celui de Microsoft, donc cela a créé des confusions.
