[Kos-dev] RE: Kos-dev digest, Vol 1 #3 - 1 msg

[Christophe Avoinne]

Fabrice Gautier a écrit :

> Est-ce qu'il ne faudrait pas plutot avoir pour les in:
>
> asm volatile ("in %1,%0" : "=a"(value):"Nd"(index)); }

Exact :-).

Il y a une autre correction, il faut remplacer :
- soit "in %1,%0" par "in %w1,%0" et "out %0,%1" par "out %0,%w1"
- soit ou "(index)" par "((short)index)".

Le résultat est le même, mais il est impératif que "in" ou "out" soit utilisés
avec %dx et non %edx, sinon gcc et as se plaignent.

Pour répondre à ta deuxième question, dans les faits, il n'y a pas grande
différence, excepté une.

extern inline int f(void);
static inline int f(void);

1) Ce qu'il y a de commun :

Tous les deux évitent la génération du code suivant dans le fichier .c qui font
appel au .h contenant l'une de ces deux fonctions :
.global f
.type f,@function
f:
  ...
  retn
...

2) Ce qui diffère :

si on définit une variable comme suit : int (*fp)(void) = f;

fp doit contenir l'adresse de la fonction f, or si on définit avec "extern
inline int f(void)", la référence étant externe, il ne sera jamais généré nulle
part dans le fichier objet et donc on aura une référence externe non résolue
quand on voudra créer l'exécutable. A l'inverse, si on définit avec "static
inline int f(void)", la référence à l'adresse de f par fp provoque la génération
du code de la fonction f dans le fichier objet, et donc la création de
l'exécutable est possible, mais un inline tout court est aussi possible.

L'inconvénient avec static, c'est que la fonction est non globale, donc si deux
fichiers .c supporte chacun un "int (*fp)(void) = f;", chacun de ces fichiers
compilés auront une version en double de f, ce qui est redondant surtout si l'on
compte ensuite lier les deux fichiers objets obtenus.

Bref, s'il n'y a pas de int (*fp)(void) = f;, je penses qu'extern ou static est
indifférent, sinon il faut préférer un static avec le risque de redondance. Un
inline tout court n'est pas satisfaisant, car chaque fichier objet aura un code
de f généré et d'accès global : à l'édition de lien, il y aura conflit car
chacun présentera sa fonction globale f.

Voilà, tout ça c'est mieux expliqué dans : info gcc, rubrique : *gcc extensions,
*inline...

amicalement,

Hlide