Les directives d'assemblage de A68k - Page 1

Comment faire un

#ifdef MACHIN

#else

#endif

?

Cf. http://tigcc.ticalc.org/doc/a68k.html#directives

désolé pour le HS, mais comment sait on avec tigcc qu'on est sur un 68k? J'ai demandé à kevin mais il doit être occupé, il m'a pas encore répondu.

Brayf, #if defined(m68k) || defined(__m68k) est pas defini sous tigcc

Ben tigcc ne compile que pour 68k, donc il n'y a pas d'ambiguïté possible si ?

Il fait peut-être un programme compilable pour plusieurs plateformes ?

Martial : j'ai déjà regardé et j'ai rien compris
PpHd : merci bien !!!

j'ai un code multiplateforme dont l'une d'entre elles est tigcc

TIGCC définit __TIGCC_ENV__, ensuite il y a aussi __m68k__ et __mc68000__ qui sont définis par GCC.

Mais je conseille de ne pas détecter l'endianness comme ça, ou plus précisément de ne pas détecter l'endianness du tout, mais de coder de manière indépendante de l'endianness et des autres particularités d'un CPU particulier! Ces defines, à la limite ils servent pour de l'assembleur inline, mais sinon le code C a intérêt à marcher sans.

on est bien d'accord, répondu par mmsg, je vais traiter des fichiers codés en bigendian et pas par moi

Ça n'empêche pas de coder en endian-independent. ld-tigcc ne détecte nulle part l'endianness de la machine hôte.

La solution est de lire ton fichier octet par octet, et de recomposer les octets de manière indépendante de l'endianness, par exemple:
((uint32_t)*p<<24)+((uint32_t)p[1]<<16)+((uint32_t)p[2]<<8)+(uint32_t)p[3]

La solution de ld-tigcc:
http://tigcc-linux.cvs.sourceforge.net/tigcc-linux/tigcc/ld-tigcc/integers.h?revision=1.2&view=markup
http://tigcc-linux.cvs.sourceforge.net/tigcc-linux/tigcc/ld-tigcc/integers.c?revision=1.1&view=markup
http://tigcc-linux.cvs.sourceforge.net/tigcc-linux/tigcc/ld-tigcc/int_def.inc?revision=1.1&view=markup

Voilà, j'ai fini de porter les sources d'Einstein pour GTC vers TIGCC.

(Pas mal le nouveau linker de TIGCC. Einstein a perdu près d'un kilo octet.)
J'ai pas encore essayé de compiler avec le nouveau GTC.

[edit] : en fait c'est la directive -Os qui a réduit de 1 ko la taille du binaire. En compilant avec -O2, comme avant, la taille est à peine changée par rapport à avant.

Pollux avait une copie des sources.

Thibaut (./11) :
Pas mal le nouveau linker de TIGCC. Einstein a perdu près d'un kilo octet.

Donc le "compilateur obsolète" (comme tu l'appelles) t'a fait gagner un kilo-octet par rapport au compilateur que tu retiens le meilleur du monde?

T'as rien compris... Enfin, tu fais exprès de ne pas comprendre. Bref.

J'ai pas le fichier de données qui va avec cette version du programme.
Pollux, as-tu un fichier nommé einsdata.9xz dans l'archive que je t'avais passée ?

Si tu veux une fois de plus faire l'apologie de TIGCC et présenter ses avantages, Kevin, je t'invite à poursuive dans un des nombreux topics à ce sujet existant sur le forum.

De plus, prend des leçons d'humilité et de tolérance. Tu es de plus en plus catastrophique sur ce point.

Tiens, le fichier compressé est plus gros par contre Le binaire perd 1000 octets mais le PPG gonfle de 50 octets !

Code mieux optimisé = moins de redondance = moins bonne compression. Donc parfois ça fait grossir le PPG.
Si ce sont des variables qui se retrouvent en BSS, ce sont carrément des plages de zéros qui dégagent, qui se compressent très bien, mieux que les relogements BSS qui les remplacent. Pour tester si c'est ça, essaie de compiler avec -mno-bss et regarde ce que ça donne.
Si c'est le code lui-même qui est à l'origine de ça: Malheureusement l'optimisation pour taille compressée n'est pas quelque chose d'activement recherché par le projet GCC.

Kevin Kofler (./14) :

Thibaut (./11) :
Pas mal le nouveau linker de TIGCC. Einstein a perdu près d'un kilo octet.

Donc le "compilateur obsolète" (comme tu l'appelles) t'a fait gagner un kilo-octet par rapport au compilateur que tu retiens le meilleur du monde?

Euh, tu dis n'importe quoi Kevin. Il comparait la taille entre les deux versions de TIGCC, pas entre GTC et TIGCC...

Si tu tiens absolument à comparer GTC et TIGCC, sache que la version compressée avec GTC (avec lanceur intégré à l'exécutable) est plus petite que le PPG généré par TIGCC (qui nécessite en plus un lanceur externe !)

D'ailleurs je suis désolé d'apprendre à Kevin qu'Einstein a perdu 1000 octets grâce à ... -Os !

Je viens de m'apercevoir qu'en compilant avec -O2, il ne perd que quelques dizaines d'octets. C'est cette comparaison qu'il faut prendre en compte, car Einstein était compilé avec -O2 sur l'ancien TIGCC.

De plus, je constate qu'il y a un gros plantage à l'exécution du binaire généré par le nouveau TIGCC. Je vais compiler avec GTC pour voir si le plantage a lieu aussi (à priori non, puisqu'à l'époque ça allait).

Je ne suis pas sûr qu'il soit désolé d'apprendre qu'Os fait correctement son boulot par rapport à O2

Non, ce dont je suis à peu près sûr, c'est qu'il sera désolé d'apprendre que le nouvel éditeur de liens n'a pas fait les miracles attendus

Pour la suite du débat sur la taille d'Einstein : topics/103139-le-compilateur-gtc-est-il-mauvais

-Os s'est aussi amélioré pas mal avec les GCC récents, avec les GCC anciens ça ne faisait pas beaucoup de différence par rapport à -O2.

ASM_call (cptr + 0x40002);

Pour lancer un programme :EX_patch (cptr + 0x40002, cptr + plen + 0x3FFFE);

Ce code, qui se trouve dans la documentation de TIGCC 0.95, marche sur Titanium ?

Non.

D'accord. Sais-tu où je peux trouver des explications pour porter ce code sur la Titanium ?

kernel__exec ? Je ne supporte pas une autre méthode.