1

yop,


Quand on donne à un fichier le tag OTH_TAG, on peut également lui donner une extension personnalisée, visible dans le Var-link, et probablement dans les shells, en préfixant le tag de "\0abcd\0".
Je sais que la longueur maximale pour ce tag est de 4, que 3 est accepté, maintenant j'aimerais savoir si les longueurs 1 et 2 sont supportées pour tous les AMS, s'il y a quelque chose de standardisé de ce côté.

La doc des toolchains dit ça : "TIOS then expects that a real type name is stored just below OTH_TAG as a zero-started zero-terminated string of maximum 4 chars."
Mais je n'ai jamais vu d'extension de 1 ou 2 caractères. C'est légal ?


Merci d'avance. smile

2

la doc parle de maximum, pas de minimum, donc oui 1 ou 2 est autorisé ^^
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

3

4

féchier, ya tous les AMS à se fader et je ne les ai pas...

5

a mon avis ça marche partout pareil grin

6

Pour les patches d'OS, ça n'est pas faisable, mais pour ce genre de choses, un sampling du genre AMS 1.05 (dernier AMS 1.xx) + 2.03 (premier AMS 2.xx utilisable) + 2.09 (dernier AMS 2.xx) + 3.10 (dernier AMS en date) donnerait des résultats dans lesquels on peut avoir raisonnablement confiance, sans devoir tester la série complète.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

7

Pas bête, merci je regarde. smile

8

La vache, je vais pas faire un topic pour le dire, mais A68k (ou le linker plutôt) ne sait pas faire naturellement des sauts courts entre fichiers sources, faut le faire à la main fou

9

D'où, je crois, le truc super propre qui consiste à faire n "include mySource_n.s" dans un source assembleur racine \o/


Enfin le problème est que le linker n'a normalement pas pour but de modifier le binaire généré. Or un saut long n'est pas un saut court, et comme qui peut le plus peut le moins toussah cheeky

10

Oui, je comprends maintenant les include de .asm.
Je dirais que c'est crade pour un langage de moyen/haut niveau avec des abstractions toussa. L'assembleur, je ne considère pas ça comme un langage, c'est de l'instruction pure, on organise chaque octet de son binaire final. En fait, la notion d'implémentation n'existe pas comme dans les autres langages. Donc je ne considère pas que grouper des sources comme bon nous semble soit sale : tant qu'on maitrise ce qu'on fait, tout va bien.

D'ailleurs, je vais faire ça à partir d'aujourd'hui grin

Le truc par rapport au fait que les sauts restent longs, c'est que A68k sait, dans un même source, transformer les bxx en bxx.s quand c'est possible. Ca fait des écritures pas très réglo en soi (bxx tout seul, ça ne correspond pas à une instruction), mais faut avouer que c'est bien commode.
Donc je m'attendais bêtement à ce que le linker fasse la même chose entre deux sources, mais en fait, il n'ose visiblement pas modifier ça. Je n'ai fourni aucun switch d'optimisation faut dire (juste --optimize-nops). Bon à savoir. smile

11

Il me semble que je ne sais plus trop quel linker pour TI était censé transgresser tout ça et optimiser les sauts courts/longs entres fichiers objets.

D'autres te diront ça mieux que moi smile

12

Ben le problème, c'est qu'en transformant un saut, on décale tout ce qui suit non? Donc on risque de fausser d'autres sauts...
avatar
Maintenant j'ai la flemme de garder une signature à jour sur ce site. Je n'ai même plus ma chaîne Exec sous la main.

13

Oui, quand on assemble par fichier c'est ce qui se passe. Immaginons :
1.asm :

A:

2.asm :

        bsr.s B
        bsr   A
B:

A l'assemblage (deuxième passe je pense), A68k va fixer le 'bsr.s B' à sa taille et à son offset définitf, et à priori ne garder aucune trace de cette instruction (le saut étant entièrement résolu).
Mais évidemment, il va devoir émettre qqchose dans l'objet pour que le linker calcule le 'bsr A'. Et donc il doit, faute d'informations suffisantes, prévoir un 'bsr.w A', le 'bsr.s B' ne pouvant plus être modifié.

Il y a deux moyens d'optimiser ce genre de sauts d'après moi :

1. Dire à l'assembleur de ne pas chercher à calculer les références pc-relatives dans un même source, laissant ce boulot au linker (sauf si le codeur a imposé les longueurs, alors ces offsets doivent être marqués non-optimisables).
Le linker peut utiliser alors une méthode de "décompression" du code : il commence par dire que partout, les saut sonts courts. Ensuite, il vérifie chaque saut, en étendant à deux octets ceux qui au final ne tiennent pas sur un seul octet. Une fois qu'il a fait une passe où rien n'a changé, il peut considérer qu'il a complètement optimisé les branchements.

2. Dire à l'assembleur de garder une trace des sauts résolus (longueur imposée ou non, offset) dans l'objet, afin que le linker puisse adapter les offsets déjà calculés par l'assembleur.
Puis la même méthode de linking.


Ce n'est qu'une différence de main d'oeuvre au final. D'un côté on fait bosser l'assembleur, de l'autre côté le linker.
J'imagine qu'un codeur puriste de l'assembleur voudrait que son assembleur lui calcule ses sauts, il sait quand même ce qu'il a écrit, c'était pas au hasard, et son assembleur chéri sait le faire dans la seconde passe. Tandis qu'un accro du linker préférera qu son linker favori s'occupe de tout ce qui est offset sans que l'assembleur vienne mettre les doigts dedans.

En fait, je ne sais pas ce qui est le mieux, mais les deux méthodes donnent le même résultat grin

14

Folco (./13) :
Le linker peut utiliser alors une méthode de "décompression" du code : il commence par dire que partout, les saut sonts courts. Ensuite, il vérifie chaque saut, en étendant à deux octets ceux qui au final ne tiennent pas sur un seul octet. Une fois qu'il a fait une passe où rien n'a changé, il peut considérer qu'il a complètement optimisé les branchements.
Il me semble que tu ne peux pas être certain d'avoir le code le plus compact sans tester toutes les possibilités.

15

11: j'imagine qu'il est capable de recalculer les offsets des trucs qui suivent, sinon ça sert pas à grand chose, à part pour insérer des NOP grin

16

squalyl (./15) :
11: j'imagine qu'il est capable de recalculer les offsets des trucs qui suivent, sinon ça sert pas à grand chose, à part pour insérer des NOP biggrin.gif

Il faut alors que l'assembleur garde une trace de ces références dans l'objet, comme j'ai dit dans la méthode 2.
Pen^2 (./14) :
Il me semble que tu ne peux pas être certain d'avoir le code le plus compact sans tester toutes les possibilités.

Si, si tu pars du principe que toutes les références sont courtes (compression), puis tu n'étends que celles qui ont besoin de l'être (expansion). Cette méthode n'est pas de moi, mais je ne connais pas son nom. C'est Kevin qui me l'avait suggérée.

17

Ben, vu de loin, j'ai l'impression que non : les résultats de ton algo doivent probablement dépendre de l'ordre des expansions (=passages aux sauts longs)

18

Ben... confus


Tu fais x passes, en prenant les références dans l'ordre où elles se présentent dans le binaire, jusqu'à ce qu'une passe ne change rien. Chaque fois, tu adaptes ce qui doit l'être, donc au final, tu n'auras fait que les expansions strictement nécessaires, toutes les autres références seront restées des références courtes vu qu'elles n'auront pas eu à être étendues. Quelle référence pourrait devenir longue alors qu'elle pourrait ne pas l'être ? Et si aucune référence n'est dans ce cas, alors on est optimal, non ?

19

Personnellement, j'aurais plutôt utilisé la méthode inverse: Partir du principe qu'elles sont longues, et compresser.

Mais dans les deux cas, il est important de tout faire dans le même sens, pour être sûr de ne jamais faire une action nécessitant l'opération inverse (si on ne fait que compresser, pas de risque d'allonger accidentellement un saut, et inversement).
avatar
Maintenant j'ai la flemme de garder une signature à jour sur ce site. Je n'ai même plus ma chaîne Exec sous la main.

20

Link (./19) :
Personnellement, j'aurais plutôt utilisé la méthode inverse: Partir du principe qu'elles sont longues, et compresser.

Bonsoir le merdier grin

En fait, tu vas te dire : "Bon, je peux pas compresser bxx1" ... "ah si, sauf si j'arrive à compresser bxx2 et bxx3 qui sont dedans" ... "ah oui, mais bxx2 comprend bxx3 aussi, et bxx4 également" ... "alors sachant que bxx4 comprend lui aussi un petit bout de bxx2 et bxx3, mais aussi bxx5, donc bon euh...", ... "j'en étais où déjà ? ah oui, bxx1". Bon ben je sais toujours pas ce que je peux en faire de ce con-là" grin

Alors qu'expand, c'est beaucoup plus simple : "dois-je expand bxx1 ? oui/non -> expand/pas expand". Et on continue. On a pas à se soucier du reste, on est dans un objet, on calculera les distances de bxx2 et consorts quand on arrivera dessus. cheeky
Autre avantage, si on décompresse une référence, on est certain qu'on aura pas à la recompresser, donc on ne peut pas se planter.

21

Folco (./18) :
Tu fais x passes, en prenant les références dans l'ordre où elles se présentent dans le binaire
Quel ordre ? Tu peux linker tes n fichiers .o dans n'importe quel ordre, non ?

22

Aaaaah, ok, je parlais pas de ça. grin Dans ma psychologie d'assembleuriste, tu linkes tes fichiers dans l'ordre où toi-même tu l'as choisi toi et toi seul grin

Sinon oui, il y a des algos heuristiques pour ça, mais à part tout essayer, je crois qu'il n'y a rien. A ce moment-là, tu as raison. oui
Mais tu parlais de l'agencement des sections et moi uniquement des résolutions de références.

Ce que je disais se rapporte à la réduction des références (ou plutôt à leur expansion) dans un fichier source unique, ou dans un source qui en inclus d'autres, ou dans le cas où tu connais l'ordre de linking de tes fichiers. Cas que j'ai évoqué au début de cette discussion, parce que visiblement ld-tigcc ne sait pas réduire ces références naturellement, du moins sans switches. Et en assembleur, je ne laisse pas le soin au linker de bouger mes fichiers, non méh oh !!! vtff

23

Folco, je pense que c'est pareil dans les deux sens. Pour l'expansion aussi tu parlais de plusieurs passes successives et ne rien faire si ça ne change pas. C'est exactement la même chose.

Et quand tu compresses, tu es aussi certain que tu n'auras pas à décompresser.
avatar
Maintenant j'ai la flemme de garder une signature à jour sur ce site. Je n'ai même plus ma chaîne Exec sous la main.

24

Link (./23) :
Folco, je pense que c'est pareil dans les deux sens. Pour l'expansion aussi tu parlais de plusieurs passes successives et ne rien faire si ça ne change pas. C'est exactement la même chose.

Ben pose ton algo sur papier, tu verras que c'est loin d'être aussi évident que tu penses cheeky Je l'ai déjà fait plus d'une fois pour celui que j'ai donné (v4p0r powa), amha c'est de loin le plus simple.

Plusieurs passes != (récursif et qui dépend de plein d'autres références en même temps). C'est juste un while (flagCaAChangé){ for_each(bxx.s); ...}, rien de plus.

Et notamment, tu tomberas sur le cas bien emmerdant où bxx1 est réductible à la condition que bxx2 le soit aussi etc...

25

Ah, je crois que je vois ce dont tu veux parler. Pour deux sauts qui overlappent mais ne sont pas imbriqués...

Je pensais faire un truc beaucoup plus naïf que ça, qui n'aurait pas détecté ce cas-là.
avatar
Maintenant j'ai la flemme de garder une signature à jour sur ce site. Je n'ai même plus ma chaîne Exec sous la main.

26

Oui, genre :
Label1:
bsr Label2
bsr Label1
Label2:

Alors les imbrications d'imbrications, je te raconte pas la mouise. J'étais parti sur ta méthode et c'est Kevin qui m'avait très justement réorienté ^^

27

Ouay, fiston qui m'aide à programmer :

Jz8G

Bon, par contre, il code avec une police de gamin évidemment, donc c'est pas très lisible embarrassed

28

Tiens,
        moveq.l #0,d0
        move.w  (a0),d3
        btst.l  #0,d3
        beq.s   \Even
                addq.l  #1,d3
\Even:  addi.l  #20,d3

=>
        moveq.l #21,d3
        add.w   (a0),d3
        andi.w  #$FFFE,d3

Merci PpHd, c'est ton code pour aligner les tailles au word supérieur dans HeapAlloc qui m'a donné l'idée hehe

(ok, faut rajouter un bvs/bvc pour les fichiers > 65535-21 bytes, pour être parfaitement safe)