Changement de syntaxe - Page 2

J'étais sûr que tu dirais ça

Moi ce que je lis c'est ça :

Y'a pas d'équivalent de __fastcall de Visual C++ sous GCC ?

La réponse qu'il attend, c'est donc un équivalent de __fastcall. Ca existe, donc autant lui dire plutôt que de lui faire allouer à la main les registres pour les paramètres (surtout que en général qd on fait ça à la main on fait des bêtises, du genre bouffer plein de registres dont la fonction appelante pourrait avoir besoin, etc...)

Et puis moi je m'en fous, de toute façon GTC 2 supprimera tous ces trucs "faits à la main" si il voit que c pas utilisé dans du code asm. Donc ça rendra juste incompatible avec GTC on-calc (ou bien ça réduira seulement les performances, je vais voir) et ça générera du code moche sous TIGCC. GTC en sort gagnant Non enfin sérieusement dans son cas c'est pas du tout adapté.

Pollux :
Moi ce que je lis c'est ça :

Y'a pas d'équivalent de __fastcall de Visual C++ sous GCC ?

La réponse qu'il attend, c'est donc un équivalent de __fastcall. Ca existe, donc autant lui dire plutôt que de lui faire allouer à la main les registres pour les paramètres

Mouais, je suis persuadé que si GTC n'utilisait pas cette syntaxe tu n'aurais rien rajouté.

(surtout que en général qd on fait ça à la main on fait des bêtises, du genre bouffer plein de registres dont la fonction appelante pourrait avoir besoin, etc...)

Bof, il suffit de savoir ce que l'on fait.

Et puis moi je m'en fous, de toute façon GTC 2 supprimera tous ces trucs "faits à la main" si il voit que c pas utilisé dans du code asm.

Tu veux dire si le corps de la fonction est en C ?
Dans ce cas, tu as parfaitement raison.

Mouais, je suis persuadé que si GTC n'utilisait pas cette syntaxe tu n'aurais rien rajouté.

Si, très probablement. Seulement je n'aurais peut-être pas insisté tant sur le fait que ta réponse était à côté de la plaque parce que je n'aurais pas eu ce gros doute sur ta bonne foi

Bof, il suffit de savoir ce que l'on fait.

Bah oui mais non. A moins de bien connaître l'asm, on fait souvent n'importe quoi (et ici, rien ne te dit que BlackVailor connaît bien l'asm 68k). Je ne compte plus les progs avec des "optimisations" asm qui sont vraiment affreuses

Tu veux dire si le corps de la fonction est en C ? Dans ce cas, tu as parfaitement raison.

Oui, enfin ça ne suffit pas, il faut aussi qu'elle soit appelée seulement par des fonctions C.

Sasume
:

Pollux
: Et puis moi je m'en fous, de toute façon GTC 2 supprimera tous ces trucs "faits à la main" si il voit que c pas utilisé dans du code asm.

Tu veux dire si le corps de la fonction est en C ? Dans ce cas, tu as parfaitement raison.

Pas du tout! Si on spécifie les registres d'une certaine manière, c'est pour une raison!

... cette raison pouvant être qu'on lui a dit de spécifier lui-même ses registres. En tout cas je ne vois pas comment l'utilisateur aurait le droit d'en attendre un comportement différent, puisque le compilo peut parfaitement décider au début de la fonction de remplacer les valeurs de ces registres par autre chose. D'ailleurs c'est parfaitement analogue au mot-clé "register" à l'époque où les compilos ne savaient pas optimiser : maintenant, GCC ignore complètement le mot-clé, et tant mieux (et pourtant, si le programmeur mettait un mot-clé "register", c'est qu'il y avait une raison!)

Kevin Kofler
: Pas du tout! Si on spécifie les registres d'une certaine manière, c'est pour une raison!

Ah, je n'ai peut-être pas pensé à un cas de figure où ce serait vraiment utile alors.
Je pense effectivement que si une fonction en C appelle une autre fonction en C, il est inutile de préciser où sont passés les paramètres de la fonction appelée.

Sasume > Je suppose que si je ne précise pas directement les arguments, mais que je passe des
variables, il vaut mieux déclarer celles-ci en register ?

Je ne suis pas sûr de bien comprendre ce que tu dis, tu peux réexpliquer ?

Loupé une page

Disons:

void DispStr( char* str asm("a0"));

Je l'appelle: DispStr("Truc");

Si je met:

char* monstr="Truc";
DispStr(monstr);

Je pense donc que ça optimisera de déclarer:

register char* monstr="Truc";

Au lieu qu'il reste en auto.

Je ne pense pas, d'après le post ./35

Faudra faire des listings.

Le mieux à mon humble avis est de laisser le compilo faire ce qu'il sait faire, à savoir l'allocation de registre, donc écrire :

void __attribute__((regparm)) DispStr(char* str);

est bien plus propre que :

void DispStr( char* str asm("a0"));

(sauf si tu as une raison particulière de mettre str dans a0 et pas dans a1 ou un autre registre ; et d'ailleurs même si tu voulais mettre 'str' dans a0, il y aurait quand même moyen de le faire en utilisant __attribute__((regparm(1))), mais ça c'est encore une autre histoire).

Oui... mais:

1) Je dois faire un listing pour voir quel registre sera utilisé, non ?

2) Est-ce que le même registre sera utilisé à chaque fois, si le compilo décide ?
Si c'est pas le cas, ...

Je dois faire un listing pour voir quel registre sera utilisé, non ?

Ben oui, mais ça dépend de ce que tu veux en faire. Si c'est juste pour t'assurer que c'est bien alloué dans un registre, oui (ou si c'est pour pouvoir débugger avec VTI et spécifier "à la main" tes paramètres). Mais si, comme le sous-entend ton point 2, c'est pour l'utiliser dans du code ASM en faisant :

move.l xxx,a0
bsr DispStr

alors c'est plus propre d'utiliser asm("a0") ou encore __attribute__((regparm(1))) (le 1 est là pour dire qu'on utilise au maximum 1 registre de donnée, D0, et 1 registre d'adresse, A0; si tu as 2 paramètres tu peux mettre regparm(2), etc...)

Est-ce que le même registre sera utilisé à chaque fois, si le compilo décide ? Si c'est pas le cas, ...

Ce sera le même registre à chaque fois si tu utilise __attribute__((regparm(n))), sauf si évidemment tu changes le prototype.
Pour ce qui est d'__attribute__((regparm)), ça dépend des options de la ligne de commande (et je te conseille d'éviter de modifier ces options toi-même et/ou de supposer que cette option est plus grande qu'un certain nombre, parce que ça ne te laissera plus la possibilité d'optimiser le code généré en réglant cette option).