Changement de syntaxe - Page 1

Peut-on configurer as de TIGCC pour adopter la syntaxe de A68k ?

(pas de %a7 par exemple, mais a7, pas de jbsr, mais bsr)

oui

Quel switch ?

ça doit être dans la doc

Non, apparemment elle ne décrit que deux syntaxes, la MIT et la Motorola, qui
utilisent toutes deux des trucs comme %a5 ou %d6 qui m'embrouillent.

pourquoi tu n'utilises pas des sources asm a68k plutôt que gnu alors?

Je veux faire du C avec de l'assembleur inline (ENORMEMENT d'assembleur inline)

Il y a --register-prefix-optional. (Quant au bsr, il est déjà compris. Mais ça te donnera toujours un bsr.w, donc mets plutôt jbsr.) Il y a aussi --mri-compat qui change quelques trucs de plus, mais je pense que ça ne va pas marcher correctement avec ce que sort GCC.

ExceedingDeath
:Je veux faire du C avec de l'assembleur inline (ENORMEMENT d'assembleur inline)

Dans ce cas, suis le conseil de Ximoon au post ./6

Ce que je ne comprends pas, c'est pourquoi tu n'utilises pas tout simplement la syntaxe GNU...
Et le conseil de Ximoon, pour de l'assembleur inline, ben il ne sert à rien.

Si il y a "énormément" d'assembleur, ça sert à rien de le mettre inline (surtout s'il veut utiliser la syntaxe standard) ^^

La syntaxe standard de TIGCC est l'assembleur GNU. A68k, c'est pour la compatibilité antérieure avec une syntaxe obsolète. Des horreurs comme l'indentation qui fait partie de la syntaxe n'ont rien à faire dans un assembleur moderne.

... tel que GTC

Meuh nan c'est la syntaxe constructeur, ça se démode pas ce genre de truc.
Et quand on enseigne le 68000, c'est celle là qu'on utilise bien sûr. Quelle idée d'en avoir pris une autre pour TIGCC, GNU ou pas, je te le demande ...

Ximoon
: Meuh nan c'est la syntaxe constructeur, ça se démode pas ce genre de truc.

GNU as comprend la syntaxe constructeur. Par exemple, tu n'es pas obligé de mettre (%sp,7), tu peux aussi mettre 7(%sp) ou 7(%a7). (Il comprend aussi la syntaxe MIT: %sp@(7), mais personne ici ne l'utilise à mon avis.) Le pourcent, c'est pour distinguer un registre d'un label. Comme ça, une variable nommée sp ou a7 marche sans problèmes!

cherche pas d'excuse, c'est pas standard c'est tout
(bon je crois que la discussion n'ira pas plus loin je suis au moins aussi borné que toi sur ce point )

Ximoon :
cherche pas d'excuse, c'est pas standard c'est tout

Le % pour les registres est standard à travers toutes les plateformes de GCC qui n'utilisent pas la convention obsolète de mettre des _ devant les traductions assembleur des variables C.

Kevin>
Ouais je vais appeler mes variables d0-d7/a0-a7/sp/usp/pc
Non sérieusement ce genre de noms de variables ça pose problème quand on porte du code _déjà écrit_, mais pas quand on en écrit du nouveau. Quand on programme en ASM, ce n'est vraiment pas un souci.

Ximoon>

Meuh nan c'est la syntaxe constructeur, ça se démode pas ce genre de truc.

Quoique, j'ai bien l'impression qu'aux débuts du 68k la mode était de toute mettre en majuscules. Maintenant, on fait tout en minuscules (plus lisible). Par contre pour les % je ne vois pas en quoi ça rend plus lisible d'en rajouter

Le % pour les registres est standard à travers toutes les plateformes de GCC qui n'utilisent pas la convention obsolète de mettre des _ devant les traductions assembleur des variables C.

Ouais, cool, comme ça on va pouvoir compiler de l'ASM 68000 vers un UltraSPARC
Sérieusement, on s'en tape des conventions de GCC. Les conventions de GCC, pour être clair, c'est des conventions qui sont faites pour écrire des petits fragments d'ASM qui ne doivent jamais entrer en conflit avec le moindre bout de code (heureusement, vu la diversité des plateformes). Si on veut faire un prog en ASM pur, pour 68000, ce n'est pas du tout la convention à utiliser.

Pollux :
Kevin> Ouais je vais appeler mes variables d0-d7/a0-a7/sp/usp/pc

Le standard C permet ces noms de variables, donc GCC doit les gérer.

grmbl! Oui, dans du code C pur, GCC doit les gérer. Par contre le "standard C" ne te dit pas si ces variables doivent être accessibles ou pas à partir du code C!

en quoi les conventions d'écriture d'un seul freeware et dans des cas limités pourraient valoir plus que les normes constructeur ? c'est bien une manie de nunuxien ça, on fait un truc compliqué, on y appose un "norme standard GNU" et y on fait référence aveuglément par la suite... (ça va même jusqu'à des personnes qui ne sont pas aidées parcequ'elles n'utilisent pas la syntaxe propriétaire du freeware, avec pour seule réponse de réécrire leur code, c du joli)

Bon, autre question (surtout adressée à Kevin, qui connaît bien le GCC)
Y'a pas d'équivalent de __fastcall de Visual C++ sous GCC ? (Pour faire un passage de paramètres par registres)

Pour préciser que tu veux passer les paramètres par les registres, il te suffit de préciser le nom du registre derrière le paramètre : void fonction(short param1 asm("%d0"),short param2 asm("%d1"),void *param3 asm("%a0")) par exemple.

Merci

Et ça marche sous TIGCC ?

Oui oui.
Je ne sais pas si ça marche ailleurs d'ailleurs.

BlackVailor :
Merci
Et ça marche sous TIGCC ?

c'est pour TIGCC, ça...

Je m'en doutait, vu qu'il employait un exemple avec les registres du 68k.
Mais comme le GCC Ti n'est pas forcément aussi complet que sur les autres plate-formes,
(Kevin va me flinguer), c'était p-ê pas implémenté.

(one more time...)

Si tu veux l'équivalent du __fastcall, ce n'est pas la syntaxe gore avec des asm("%dn") qu'il te faut (cette syntaxe-là est plutôt prévue pour interfacer avec des routines asm), mais __attribute__((regparm)). Tu peux même faire #define __fastcall __attribute__((regparm))

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

Bon, aies au moins l'honnêteté de dire les choses jusqu'au bout : c'est pour que sa source soit compatible avec GTC...

Sinon, perso, je préfère préciser moi-même quels registres jutilise.
BlackVailor> à toi de choisir