Adressage d'un label - Page 1

yop,


Je constate ce genre de comportements avec A68k, sans optimisation de linking :

_main:
        bra *
        move.w _main,d0

produit un move.w -4(pc),d0
Pourquoi un adressage pc-relatif alors qu'on a rien demandé ?
Ensuite :

_main:
        bra *
        move.l _main,d0

produit la même chose, adressage pc-relatif, sauf qu'on lit évidemment 4 octets (donc le 60FE du bra *, puis l'opcode du move). Mais le côté pc-relatif de l'adressage me laisse perplexe.

Maintenant, rajoutons un #:

_main:
        bra *
        move.w #_main,d0

produit un move #$FFFC,d0, sans relogement ??? WTF ???
Enfin :

_main:
        bra *
        move.l #_main,d0

produit enfin, grâce à un relogement, un move.l <adresse de _main>,d0


Donc mes questions, puisque j'ai les mains dans la mélasse :

1. Doit-on présupposer un adressage pc-relatif quand c'est pas demandé ? Amha non. Mais qu'en pensez-vous ?

2. Et que signifie, au juste, move.w _main,d0 ? Comment interprêtez-vous cette instruction ?
Pour moi, ça n'a pas de sens.

3. Quid du move.w #_main,d0 ? Pourquoi me sort-il une valeur de son chapeau ? Pour moi, faut émettre un relogement à l'assemblage, et une erreur de linking si le relogement ne tient pas sur deux octets (typiquement dans le cas d'une BSS, lors du linking d'un OS).

Voilà, merci de m'aider à y voir lus clair, pour en tirer quelque chose de générique.

Folco (./1) :
1. Doit-on présupposer un adressage pc-relatif quand c'est pas demandé ? Amha non. Mais qu'en pensez-vous ?

Ça dépend. Si tu as une feature qui optimise le code généré en taille et qu'elle est activée, ça se défend (de même que le remplacement auto d'un bra par un bra.s par exemple). Dans le cas contraire, clairement pas.

Folco (./1) :
2. Et que signifie, au juste, move.w _main,d0 ? Comment interprêtez-vous cette instruction ?Pour moi, ça n'a pas de sens.

Tu parles bien de la version sans # ? Je ne vois pas ce que ça a de spécial.
La version avec un # est... étrange, mais pas absurde, va savoir si y'a pas un cas où ça pourrait être utile.

Folco (./1) :
3. Quid du move.w #_main,d0 ? Pourquoi me sort-il une valeur de son chapeau ? Pour moi, faut émettre un relogement à l'assemblage, et une erreur de linking si le relogement ne tient pas sur deux octets (typiquement dans le cas d'une BSS, lors du linking d'un OS).

Pour moi, ce que génère A68k dans ce cas est clairement un bug. En toute logique, pour du code non relogeable, il devrait utiliser la valeur du mot inférieur de l'adresse. Pour du code relogeable, générer un message d'erreur (à moins que le format de sortie supporte ce genre de trucs exotiques, mais ça m'étonnerait )

Zerosquare (./2) :

Folco (./1) :
2. Et que signifie, au juste, move.w _main,d0 ? Comment interprêtez-vous cette instruction ?Pour moi, ça n'a pas de sens.

Tu parles bien de la version sans # ? Je ne vois pas ce que ça a de spécial.

Ok, mais à quoi tu t'attends comme résultat ? Si tu as écris ça, tu as voulu dire quoi ? Moi j'en vois pas le sens en tout cas.

Zerosquare (./2) :

Folco (./1) :
3. Quid du move.w #_main,d0 ? Pourquoi me sort-il une valeur de son chapeau ? Pour moi, faut émettre un relogement à l'assemblage, et une erreur de linking si le relogement ne tient pas sur deux octets (typiquement dans le cas d'une BSS, lors du linking d'un OS).

Pour moi, ce que génère A68k dans ce cas est clairement un bug.

Zerosquare (./2) :
En toute logique, pour du code non relogeable, il devrait utiliser la valeur du mot inférieur de l'adresse.

Comment veux-tu obtenir l'adresse sans relogement ? Et le "mot inférieur de l'adresse", je vois bien ce que tu veux dire, mais conceptuellement, ça a un sens ?

Zerosquare (./2) :
Pour du code relogeable, générer un message d'erreur (à moins que le format de sortie supporte ce genre de trucs exotiques, mais ça m'étonnerait )

Relogeable statiquement ou dynamiquement ?

---

Zerosquare (./2) :
une feature qui optimise le code généré en taille

mon avis très très personnel : "optimisation" et "assembleur" ne font pas bon ménage

Zerosquare (./2) :
de même que le remplacement auto d'un bra par un bra.s par exemple

amha, c'est pas de l'optimisation ça, c'est juste que, sans longueur précisée, l'assembleur fait ce qu'il veut. C'est à dire qu'il va exporter un relogement, et un linker intelligent utilisera le mode d'adressage le plus court possible

Folco (./3) :
Ok, mais à quoi tu t'attends comme résultat ? Si tu as écris ça, tu as voulu dire quoi ? Moi j'en vois pas le sens en tout cas.

Ben lire un mot à l'adresse de _main, donc récupérer l'opcode du bra *, tout simplement
Bon, dans l'exemple ça n'est probablement pas très utile (à moins de faire du code automodifiant à l'envers : du code qui se lit lui-même ), mais je ne vois pas où est le souci sur le principe

Folco (./3) :
Comment veux-tu obtenir l'adresse sans relogement ? Et le "mot inférieur de l'adresse", je vois bien ce que tu veux dire, mais conceptuellement, ça a un sens ?

Alors je ne sais pas si ça existe sur TI, mais tu as des cas où toutes les adresses sont absolues et connues au moment du linking, voire de l'assemblage, donc y'a aucun relogement. Sur les plateformes embarquées (comme une console de jeu par exemple), c'est très courant que ton code et tes données soit chargés à une adresse fixe. Donc ça ne pose pas de problème d'obtenir le mot inférieur d'une adresse, puisque c'est une constante. Ça peut même être utile si tu as, par exemple, des données qui sont placées dans une zone $xxxx0000 ~ $xxxxFFFF : vu que $xxxx est connu, tu peux faire un tableau de pointeurs qui ne stocke que la partie basse de l'adresse, et qui est du coup deux fois plus petit.

Si tu introduis des relogements là-dedans, ben... ça devient tordu À moins que ton système de relogement ne reloge qu'à des multiples de 64 Ko (auquel cas y'a rien à changer), ou qu'il soit capable de faire des relogements sur 2 octets ET ne pas placer tes données à cheval sur un multiple de 64 Ko, ça ne marche pas. Je sais pas comment marchent les relogements sur TI mais c'est probablement pas le cas, donc dans ce cas-là -> erreur.

Folco (./3) :
mon avis très très personnel : "optimisation" et "assembleur" ne font pas bon ménage

L'éternel débat
Ce qui est sûr, c'est que ça doit être désactivable (et probablement pas activé par défaut).

Folco (./3) :
amha, c'est pas de l'optimisation ça, c'est juste que, sans longueur précisée, l'assembleur fait ce qu'il veut. C'est à dire qu'il va exporter un relogement, et un linker intelligent utilisera le mode d'adressage le plus court possible

Ça se tient.

Zerosquare (./4) :
Ben lire un mot à l'adresse de _main, donc récupérer l'opcode du bra *, tout simplement

En vertu de quel adressage du 68k ? Pour lire une donnée, je connais (an), x(an), x(an,dn), x(pc), x(pc,dn).

Zerosquare (./4) :
mais je ne vois pas où est le souci sur le principe

amha l'adressage correct est x(pc). Je vois pas pourquoi l'assembleur devrait le deviner, et donc inventer quelque chose de cohérent à la place de ce qui me semble être une erreur d'adressage

Zerosquare (./4) :
L'éternel débat

Ah bon ?
Pour moi c'est évident, j'entends que le binaire produit soit à l'image 1:1 de ce que j'écris, et que personne ne foute ses pattes sales là-dedans pour soi-disant écrire mieux que ce que j'ai fait.

Folco (./5) :
En vertu de quel adressage du 68k ? Pour lire une donnée, je connais (an), x(an), x(an,dn), x(pc), x(pc,dn).

Ben une adresse immédiate, comme ça : move.w $xxxxxxxx,d0. Si le binaire n'est pas relogeable, $xxxxxxxx est connu donc c'est plié. Sinon, ben c'est une adresse à reloger au chargement.

Les relogements sur TI portent sur une adresse, ie on peut reloger l'adresse d'un label avec #label, mais pas les données qui y sont (edit -> sauf certains ramcalls en fait ??). Sinon, comme tu le dis, on est dans le cas d'un adressage absolu, long dans ton cas, mais ce n'est pas valable en format kernel. C'est faisable par contre si on assemble un OS, puisqu'on connait toutes les adresses au linking. C'est d'ailleurs, je crois, ce que PpHd a implanté dans ld-tigcc pour PedroM.

C'est bien ça ? Ou alors j'y vois toujours pas clair ?

(je parle de manière générale, après je ne connais pas les spécificités de la TI. S'il n'est pas possible de générer un relogement dans ce cas, ça me semble plus justifié de sortir un message d'erreur plutôt que de remplacer ça par du PC relatif en douce.)

Ok. Je savais pas que tu savais pas. Dans ce cas on est d'accord. Mais j'aimerais que quelqu'un confirme que je ne me mélange pas les pinceaux dans les relogements.

(je pensais que c'était justement ta grande passion, les relogements ? )

Je me suis jamais penché sur les relogements 16 bits ajoutés pour PedroM
(sinon, oui, une haine séculaire, presque aussi forte qu'entre la perfide Albion et moi, existe entre les relogements et moi )

Bon, je crois comprendre le comportement d'A68k, pour ce code :

_main:
        bra *
        move.w _main,d0

-> où que soit le code en RAM, le contenu à l'adresse _main.w sera toujours le même : $60FE. Donc il fait comme si c'était du PC-relatif, bien qu'en vrai, l'adressage soit absolu et relogé (puisqu'on connait pas encore l'adresse de _main). Là où je suis pas d'accord, c'est que ça limite l'amplitude de l'adressage à -32/+32 ko, alors qu'en vrai, l'adressage devrait concerner une adresse >0 et <4 Go, en étant sûr que _main soit positionné dans cette plage au run-time, mais sur TI on sait pas faire, sauf dans le cas d'un OS encore une fois (relogement au linking). Donc A68k transforme le code "pour que ça marche", mais j'aime pas ça. Si on veut écrire du pc-relatif, on le fait. Si on veut un adressage court, on a le droit de l'avoir.

Par contre, pour #label, il s'agit d'un relogement d'adresse tout à fait standard, ya pas de souci. Le seul fait étrange est que A68k assemble un move.w #label,d0, qui n'aurait de sens encore une fois que dans le cas d'un OS. Là, il devrait émettre un relogement, à résoudre impérativement au linking, puisqu'on devrait être sûr que le label sera dans la place 0-64 ko.

PpHd, t'es d'accord avec ça ?

Je ne vois pas trop le problème. Pour

_main:
        bra *
        move.w _main,d0

a68k se rend compte que l'adresse relative de l'instruction courante et de _main est constante, donc il n'émet pas l'opcode stoquant l'adresse avec un relogement, mais seulement un adressage relatif au PC.
C'est très commun comme optimization par un assembleur. Mais ca peut poser problème avec les linkeurs (cf. http://tigcc.ticalc.org/doc/a68k.html#usage )
Utilise l'option -n pour ne pas le faire.

move.w #_main,d0

n'a pas beaucoup de sens, et on peut estimer que si ca compile par la chaine de compilation que c'est un buggue (car je pense que le linkeur ne gere pas ce cas).

Bon ben on semble d'accord partout alors \o/

Folco (./13) :
Le seul fait étrange est que A68k assemble un move.w #label,d0, qui n'aurait de sens encore une fois que dans le cas d'un OS. Là, il devrait émettre un relogement, à résoudre impérativement au linking, puisqu'on devrait être sûr que le label sera dans la place 0-64 ko.

Est-tu d'accord avec cette interprétation stp ?

Et enfin, pourrais-tu me parler de ce que tu as apporté à ld-tigcc pour les BSS en zone < 32ko (je crois, si j'ai bien compris) ? De quoi s'agissait-il, quel était le problème à résoudre ?

Merci bien.

Folco (./15) :
Est-tu d'accord avec cette interprétation stp ?

Oui.

Folco (./15) :
Et enfin, pourrais-tu me parler de ce que tu as apporté à ld-tigcc pour les BSS en zone < 32ko (je crois, si j'ai bien compris) ? De quoi s'agissait-il, quel était le problème à résoudre ?

Les transformations avec comme argument 1, un <ea> vers une mémoire adr.l
Je les ai transformée en un <ea> vers une mémoire adr.w si adr < 32K (ce qui est calculable car le linkeur pour PedroM alloue toutes les ressources à des adresses fixes)

Quoi ? Ca veut dire que le linker n'était pas capable d'utiliser un adressage absolu court à la place d'un long ? Ca peut se comprendre vu que ld-tigcc n'a pas été conçu à la base pour linker un OS. Sinon, merci pour tout, tout est clair maintenant.

Folco (./17) :
Quoi ? Ca veut dire que le linker n'était pas capable d'utiliser un adressage absolu court à la place d'un long ?

Oui. Le format de fichier (kernel ou nostub) ne le supporte pas.

La raison pour laquelle le patch n'a pas été mergé upstream est qu'il manque l'optimisation automatique des abs.l en abs.w pour les adresses courtes, donc ça marche seulement si 1. le code est écrit directement en assembleur et 2. on sait exactement quelles variables BSS seront adressables en abs.w (parce qu'il faut mettre des .w explicits de partout).

Tiens, salut Kevin !
Bonne année !