Promotion entiere
Le
candide
Bonjour,
D'abord, un point de vocabulaire : en français, parle-t-on de "promotion
entière" ou de "promotion intégrale" ?
D'autre part, le passage de la norme qui parle de cette question est, à
mon sens, trop fortement obscurci par une note de bas de page. Plus
précisément, il est dit :
8<--
6.3.1.1p2
()If an int can represent all values of the original type, the value
is converted to an int; otherwise, it is converted to an unsigned int.
These are called the integer promotions.(48)
La note de bas de page :
(48) -- The integer promotions are applied only: as part of the usual
arithmetic conversions, to certain argument expressions, to the operands
of the unary +, -, and ~ operators, and to both operands of the
shift operators, as specified by their respective subclauses.
>8--
Si j'ai bien lu la norme, les conversions arithmétiques usuelles
s'appliquent uniquement à des opérateurs binaires et il faut regarder
dans la norme au cas par cas lesquels sont concernés.
Concernant les "argument expressions", bon je suppose les expressions
qui sont arguments de fonctions, lesquelles sont concernées ? K&R parle
de ceci :
8<--
In the absence of a function prototype, char and short become int,
>8--
c'est à ça qu'il est fait allusion ?
Je crois que beaucoup de livres de C n'ont pas tenu compte de cette note
de pas de page. Par exemple, dans le livre de Delannoy, je lis (page
78, §3.1) :
8<--
"Aucun opérateur n'accepte d'opérandes de type char ou short."
>8--
C'est vrai ou pas ?
De même dans le livre de Braquelaire, je lis :
8<--
"Lors de l'évaluation d'une expression, un opérande d'un type intégral
caractère, entier court, champ de bits ou énumération est converti dans
le type int ou dans le type unsigned int si le type int n'est pas assez
grand pour représenter toutes les valeurs de son type. Cette conversion
s'appelle promotion intégrale. "
>8--
mais aucune allusion à la note de bas de page.
Plus généralement, avez-vous des exemples simples où la promotion
entière ne s'applique pas ?
Merci
D'abord, un point de vocabulaire : en français, parle-t-on de "promotion
entière" ou de "promotion intégrale" ?
D'autre part, le passage de la norme qui parle de cette question est, à
mon sens, trop fortement obscurci par une note de bas de page. Plus
précisément, il est dit :
8<--
6.3.1.1p2
()If an int can represent all values of the original type, the value
is converted to an int; otherwise, it is converted to an unsigned int.
These are called the integer promotions.(48)
La note de bas de page :
(48) -- The integer promotions are applied only: as part of the usual
arithmetic conversions, to certain argument expressions, to the operands
of the unary +, -, and ~ operators, and to both operands of the
shift operators, as specified by their respective subclauses.
>8--
Si j'ai bien lu la norme, les conversions arithmétiques usuelles
s'appliquent uniquement à des opérateurs binaires et il faut regarder
dans la norme au cas par cas lesquels sont concernés.
Concernant les "argument expressions", bon je suppose les expressions
qui sont arguments de fonctions, lesquelles sont concernées ? K&R parle
de ceci :
8<--
In the absence of a function prototype, char and short become int,
>8--
c'est à ça qu'il est fait allusion ?
Je crois que beaucoup de livres de C n'ont pas tenu compte de cette note
de pas de page. Par exemple, dans le livre de Delannoy, je lis (page
78, §3.1) :
8<--
"Aucun opérateur n'accepte d'opérandes de type char ou short."
>8--
C'est vrai ou pas ?
De même dans le livre de Braquelaire, je lis :
8<--
"Lors de l'évaluation d'une expression, un opérande d'un type intégral
caractère, entier court, champ de bits ou énumération est converti dans
le type int ou dans le type unsigned int si le type int n'est pas assez
grand pour représenter toutes les valeurs de son type. Cette conversion
s'appelle promotion intégrale. "
>8--
mais aucune allusion à la note de bas de page.
Plus généralement, avez-vous des exemples simples où la promotion
entière ne s'applique pas ?
Merci
La 3ème méthode revient à créer une variable temporaire sur la pile
puisque la copie est locale.
J'ai déjà répondu à l'utilisation des registres. C'est une possibilité
mais, à l'époque (dans les années 80), les machines pour lesquelles je
faisais des compilos ne disposaient pas de beaucoup de registres et on
les réservait à autre chose (comme garder des résultats de calculs
intermédiaires pour les optimiser).
Pour les structures, le plus simple est quand même de passer par
référence constante plutôt que par valeur (ça devrait être le passage
par défaut en C++, mais la compatibilité avec C a fait que...).
Faire une opération sur 8 bits peut s'avérer beaucoup plus coûteux que
la faire sur 32 bits. Tout dépend du jeux d'instructions de la machine
cible.
Qu'entends-tu par "réduire les constantes" ?
Il me semble que la deuxième partie de ton paragraphe n'a pas grand
chose à voir avec le passage d'argument par valeur.
J'ai fait un optimiseur global (basé sur les algorithmes de Morel et
Renvoise) et, dans ce cadre, on peut faire effectivement des choses
merveilleuses et d'ailleurs bien plus optimisées que ne le fera jamais
un programmeur en assembleur...
Wykaaa
Pourquoi sur la pile ? En fait avec une copie locale c'est l'optimisateur
normal (celui qui agit au niveau de la fonction) qui décide, si la structure
n'est pas effectivement utilisée il n'y a pas de copie locale, si seulement
un membre est utilisé il peut faire une simple lecture de ce seul membre, en
le gardant en registre seulement si c'est nécessaire, etc.
Un des gros problèmes (d'aucuns diraient avantage !) du C est que la gamme
des machines cibles va (dans les années 80 déjà) des microcontrôleurs ultra
simplistes (l'archétype étant probablement le 8051), aux super-ordinateurs
avec plusieurs unités de traitements dont l'ordonnancement est géré par le
compilateur (contrairement aux architectures SMP actuelles).
Plus simple pour qui ?
Dans un environnement multi-tâches (/multithread/ pour parler chébran), avec
un passage par référence (supposée) constante, tu crées une situation de
compétition (/race condition/) si par hasard ta structure doit être modifiée
dans une autre partie du programme; des fois c'est utile, des fois c'est
sans effet, mais parfois, en particulier s'il y a rechargement à plusieurs
reprises de la « référence constante » qui ne l'est pas en réalité, tu peux
avoir des bogues TRÈS pénibles à diagnostiquer...
Si on pouvait éviter de parler de C++ lorsque ce n'est pas nécessaire...
« Peut ». Dans le même genre, faire une opération sur 32 bits « peut »
s'avérer plus coûteux que la faire sur 18 bits. Cela dépend de la machine
cible, et cela fait partie des variables auxquelles je faisait allusion
ci-dessus, un des « problèmes » du C.
Maintenant, sur une machine où les opérations sur 8 bits peuvent s'avérer
beaucoup plus coûteuses que de le faire sur 32 bits, si un compilateur
s'amuse à mettre en place les optimisations dont je parlais, là je dis que
c'est un mauvais compilateur et qu'il ne vaut la peine de continuer à en
parler.
Dans un compilateur, remplacer une suite d'opérations par le résultat
qu'elle donne, et ne pas générer les instructions qui font les opérations,
seulement mettre la valeur résultat directement à la bonne place.
Et avant que Vincent ne rajoute une réponse ;-), je précise que si l'on veut
faire cela pour les opérations en virgule flottante, l'équipe qui écrit le
compilateur doit avoir une excellente connaissance de l'architecture cible
d'une part, et des (nombreux) travaux sur la théorie *et* la pratique des
opérations en virgule flottante d'autre part, et aussi avoir la pleine
conscience de limiter la future portabilité de leur produit sur les
architectures futures (histoire de ne pas tomber dans l'écueil signalé
ci-dessus, le compilateur sans intérêt); en gros, cela signifie avoir un
contrat bien juteux qui justifie de pousser dans cette voie de recherche de
performances, et une option pour désactiver cette optimisation.
Ce sont deux axes orthogonaux : l'optimisateur global va te donner des
pistes d'optimisation (par exemple s'apercevoir que tel ou tel code ne sert
à rien et peut donc être purement et simplement supprimé ; ce genre
d'optimisation « tue » les tests de performances de compilateurs, car le
résultat est infiniment meilleur que quoi que ce soit d'autre...)
De son côté le fait pour un spécialiste d'une architecture matérielle de
programmer en assembleur lui permet de grapiller deci delà des cycles ou des
instructions qui s'ils sont au bon endroit peuvent apporter un gain
significatif sur le résultat final (cela peut aussi faire exploser la
fusée).
Antoine