J'avais l'habitude d'utiliser la constante du préprocesseur i386 pour
savoir si l'architecture pour laquelle on compile est un intel i386. En
fonction de cela, je savais, par exemple, qu'un int faisait 32 bits...
Bon, certes, ce n'est pas terrible : après tout, rien n'empèche un
compilo sur i386 d'implémenter un int sur 29 bits et demi si ca le chante.
Ca me sert aussi pour l'assembleur inline, et là vous admettrez que
c'est un peut plus approprié.
Bon, mais il y a en outre un autre problème : cette constante n'est pas
universelle. D'ailleurs, je viens de remarquer que gcc ne la définissait
plus en mode C99.
D'où ma question : existe t-il des constantes pour définir
l'architecture, l'endianess, etc, qui soient "standards" ?
Et vous, comment faite vous pour ce genre de tests ?
D'où ma question : existe t-il des constantes pour définir l'architecture, l'endianess, etc, qui soient "standards" ?
Non.
Et vous, comment faite vous pour ce genre de tests ?
Les makefiles ajoutent les -Dxxx qui vont bien mais j'arrive généralement à réécrire le code qui les utilisent quand je tombe dessus.
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
Pierre Maurette
cedric a écrit:
Bonjour !
J'avais l'habitude d'utiliser la constante du préprocesseur i386 pour savoir si l'architecture pour laquelle on compile est un intel i386. En fonction de cela, je savais, par exemple, qu'un int faisait 32 bits... Je ne comprends pas tout à fait. L'architecture cible est plutôt un
élément que vous communiquez au compilateur par la ligne de commande (ou l'IDE, ou en #definissant i386): <Exemple Borland, au hasard> -3 Génère les instructions compatibles avec le mode protégé du 80386 (Défaut) -4 Génère les instructions compatibles avec le mode protégé du 80386/80486
-5 Génère les instructions Pentium -6 Génère les instructions Pentium Pro </Exemple Borland, au hasard> Il est cependant possible qu'une constanyte symbolique vous donne une indication de ce type, mais elle ne concerne que la machine utilisée à la compilation, qu'à priori vous connaissez.
Bon, certes, ce n'est pas terrible : après tout, rien n'empèche un compilo sur i386 d'implémenter un int sur 29 bits et demi si ca le chante. Sans aller aussi loin dans la découpe des bits, oui. En fait, la
taille de l'int n'a rien à voir (ou si peu) avec la cible.
Ca me sert aussi pour l'assembleur inline, et là vous admettrez que c'est un peut plus approprié. Pas vraiment. J'y reviens
Bon, mais il y a en outre un autre problème : cette constante n'est pas universelle. D'ailleurs, je viens de remarquer que gcc ne la définissait plus en mode C99. Regardez limits.h, en particulier UCHAR_MAX et UINT_MAX, ou peut-être
UCHAR_MAX et sizeof().
D'où ma question : existe t-il des constantes pour définir l'architecture, l'endianess, etc, qui soient "standards" ? Impossible, presque par définition.
Et vous, comment faite vous pour ce genre de tests ? Il y a plusieurs niveaux pour interprêter votre question:
1 - Au compîl-time - Définir une cible (génération d'un code C "optimal" pour une archi): documentation du compilateur, cad options de la ligne de commande, peut-être pragma (?). - Connaître la taille des types du C: macros de limits.h
2 - Au run-time - Vous pouvez peut-être faire quelques tests (boutisme) en C. - Mais puisque vous faites de l'assembleur inline (donc pas portable), autant faire les choses correctement et récupérer tout ce qui vous intéresse dès l'init. Si vous êtes en x86 (ou AMD64), CPUID est faite pour vous. L'endianité : mov word ptr mem, 0x0011 mov al, byte ptr mem test al (attention, trouver big ou little n'est pas toujours suffisant, il faut par exemple parfois déterminer "l'atome"). Mais bon, si vous faites de l'asm, je ne vois pas comment vous pouvez ignorer l'endianité de la machine cible. etc. En conclusion, bien distinguer: - ce qui dépend de la machine de ce qui dépend du compilateur. - ce que vous imposez de ce qui vou est imposé. - le run-time du compil-time. - Pierre
cedric <rixed@happyleptic.NOSPAM.org> a écrit:
Bonjour !
J'avais l'habitude d'utiliser la constante du préprocesseur i386 pour
savoir si l'architecture pour laquelle on compile est un intel i386. En
fonction de cela, je savais, par exemple, qu'un int faisait 32 bits...
Je ne comprends pas tout à fait. L'architecture cible est plutôt un
élément que vous communiquez au compilateur par la ligne de commande
(ou l'IDE, ou en #definissant i386):
<Exemple Borland, au hasard>
-3 Génère les instructions compatibles avec le mode protégé du
80386 (Défaut)
-4 Génère les instructions compatibles avec le mode protégé du
80386/80486
-5 Génère les instructions Pentium
-6 Génère les instructions Pentium Pro
</Exemple Borland, au hasard>
Il est cependant possible qu'une constanyte symbolique vous donne une
indication de ce type, mais elle ne concerne que la machine utilisée à
la compilation, qu'à priori vous connaissez.
Bon, certes, ce n'est pas terrible : après tout, rien n'empèche un
compilo sur i386 d'implémenter un int sur 29 bits et demi si ca le chante.
Sans aller aussi loin dans la découpe des bits, oui. En fait, la
taille de l'int n'a rien à voir (ou si peu) avec la cible.
Ca me sert aussi pour l'assembleur inline, et là vous admettrez que
c'est un peut plus approprié.
Pas vraiment. J'y reviens
Bon, mais il y a en outre un autre problème : cette constante n'est pas
universelle. D'ailleurs, je viens de remarquer que gcc ne la définissait
plus en mode C99.
Regardez limits.h, en particulier UCHAR_MAX et UINT_MAX, ou peut-être
UCHAR_MAX et sizeof().
D'où ma question : existe t-il des constantes pour définir
l'architecture, l'endianess, etc, qui soient "standards" ?
Impossible, presque par définition.
Et vous, comment faite vous pour ce genre de tests ?
Il y a plusieurs niveaux pour interprêter votre question:
1 - Au compîl-time
- Définir une cible (génération d'un code C "optimal" pour une archi):
documentation du compilateur, cad options de la ligne de commande,
peut-être pragma (?).
- Connaître la taille des types du C: macros de limits.h
2 - Au run-time
- Vous pouvez peut-être faire quelques tests (boutisme) en C.
- Mais puisque vous faites de l'assembleur inline (donc pas portable),
autant faire les choses correctement et récupérer tout ce qui vous
intéresse dès l'init. Si vous êtes en x86 (ou AMD64), CPUID est faite
pour vous. L'endianité :
mov word ptr mem, 0x0011
mov al, byte ptr mem
test al
(attention, trouver big ou little n'est pas toujours suffisant, il
faut par exemple parfois déterminer "l'atome").
Mais bon, si vous faites de l'asm, je ne vois pas comment vous pouvez
ignorer l'endianité de la machine cible.
etc.
En conclusion, bien distinguer:
- ce qui dépend de la machine de ce qui dépend du compilateur.
- ce que vous imposez de ce qui vou est imposé.
- le run-time du compil-time.
-
Pierre
J'avais l'habitude d'utiliser la constante du préprocesseur i386 pour savoir si l'architecture pour laquelle on compile est un intel i386. En fonction de cela, je savais, par exemple, qu'un int faisait 32 bits... Je ne comprends pas tout à fait. L'architecture cible est plutôt un
élément que vous communiquez au compilateur par la ligne de commande (ou l'IDE, ou en #definissant i386): <Exemple Borland, au hasard> -3 Génère les instructions compatibles avec le mode protégé du 80386 (Défaut) -4 Génère les instructions compatibles avec le mode protégé du 80386/80486
-5 Génère les instructions Pentium -6 Génère les instructions Pentium Pro </Exemple Borland, au hasard> Il est cependant possible qu'une constanyte symbolique vous donne une indication de ce type, mais elle ne concerne que la machine utilisée à la compilation, qu'à priori vous connaissez.
Bon, certes, ce n'est pas terrible : après tout, rien n'empèche un compilo sur i386 d'implémenter un int sur 29 bits et demi si ca le chante. Sans aller aussi loin dans la découpe des bits, oui. En fait, la
taille de l'int n'a rien à voir (ou si peu) avec la cible.
Ca me sert aussi pour l'assembleur inline, et là vous admettrez que c'est un peut plus approprié. Pas vraiment. J'y reviens
Bon, mais il y a en outre un autre problème : cette constante n'est pas universelle. D'ailleurs, je viens de remarquer que gcc ne la définissait plus en mode C99. Regardez limits.h, en particulier UCHAR_MAX et UINT_MAX, ou peut-être
UCHAR_MAX et sizeof().
D'où ma question : existe t-il des constantes pour définir l'architecture, l'endianess, etc, qui soient "standards" ? Impossible, presque par définition.
Et vous, comment faite vous pour ce genre de tests ? Il y a plusieurs niveaux pour interprêter votre question:
1 - Au compîl-time - Définir une cible (génération d'un code C "optimal" pour une archi): documentation du compilateur, cad options de la ligne de commande, peut-être pragma (?). - Connaître la taille des types du C: macros de limits.h
2 - Au run-time - Vous pouvez peut-être faire quelques tests (boutisme) en C. - Mais puisque vous faites de l'assembleur inline (donc pas portable), autant faire les choses correctement et récupérer tout ce qui vous intéresse dès l'init. Si vous êtes en x86 (ou AMD64), CPUID est faite pour vous. L'endianité : mov word ptr mem, 0x0011 mov al, byte ptr mem test al (attention, trouver big ou little n'est pas toujours suffisant, il faut par exemple parfois déterminer "l'atome"). Mais bon, si vous faites de l'asm, je ne vois pas comment vous pouvez ignorer l'endianité de la machine cible. etc. En conclusion, bien distinguer: - ce qui dépend de la machine de ce qui dépend du compilateur. - ce que vous imposez de ce qui vou est imposé. - le run-time du compil-time. - Pierre
cedric
Pierre Maurette wrote:
Il y a plusieurs niveaux pour interprêter votre question:
1 - Au compîl-time - Définir une cible (génération d'un code C "optimal" pour une archi): documentation du compilateur, cad options de la ligne de commande, peut-être pragma (?).
C'est bien ce la dont il s'agit. Oui, je pourrait définir une ou plusieurs variables sur la ligne de commande, mais j'aurai préféré que l'utilisateur n'ai pas à se soucier de ca (oui, c'est l'utilisateur qui compile, n'est ce pas...)
2 - Au run-time
Ca me déplait d'inclure dans le programme un test qui répondra toujours la même valeur (pour ce programme) :-)
Merci en tout cas pour vos éclaircissements.
Pierre Maurette wrote:
Il y a plusieurs niveaux pour interprêter votre question:
1 - Au compîl-time
- Définir une cible (génération d'un code C "optimal" pour une archi):
documentation du compilateur, cad options de la ligne de commande,
peut-être pragma (?).
C'est bien ce la dont il s'agit.
Oui, je pourrait définir une ou plusieurs variables sur la ligne de
commande, mais j'aurai préféré que l'utilisateur n'ai pas à se soucier
de ca (oui, c'est l'utilisateur qui compile, n'est ce pas...)
2 - Au run-time
Ca me déplait d'inclure dans le programme un test qui répondra toujours
la même valeur (pour ce programme) :-)
Il y a plusieurs niveaux pour interprêter votre question:
1 - Au compîl-time - Définir une cible (génération d'un code C "optimal" pour une archi): documentation du compilateur, cad options de la ligne de commande, peut-être pragma (?).
C'est bien ce la dont il s'agit. Oui, je pourrait définir une ou plusieurs variables sur la ligne de commande, mais j'aurai préféré que l'utilisateur n'ai pas à se soucier de ca (oui, c'est l'utilisateur qui compile, n'est ce pas...)
2 - Au run-time
Ca me déplait d'inclure dans le programme un test qui répondra toujours la même valeur (pour ce programme) :-)
