Posté le 02/02/2014 à 20:54 Membre depuis le 18/06/2001, -26079 message
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. confus

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. happy
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 02/02/2014 à 21:11 Membre depuis le 27/04/2006, 60479 messages
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 tongue)
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
Posté le 02/02/2014 à 21:21 Membre depuis le 18/06/2001, -26079 message
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.

pencil
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 ? grin
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 tongue.gif)

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 grin
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
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 02/02/2014 à 22:06 Membre depuis le 27/04/2006, 60479 messages
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 smile
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 cheeky), mais je ne vois pas où est le souci sur le principe confus
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 grin À 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 grin
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.
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
Posté le 02/02/2014 à 22:29 Membre depuis le 18/06/2001, -26079 message
Zerosquare (./4) :
Ben lire un mot à l'adresse de _main, donc récupérer l'opcode du bra *, tout simplement smile.gif

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 confus

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 biggrin.gif

Ah bon ? grin
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.
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 02/02/2014 à 22:36 Membre depuis le 27/04/2006, 60479 messages
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.
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
Posté le 02/02/2014 à 22:42Edité par Folco le 02/02/2014 à 22:57 Membre depuis le 18/06/2001, -26079 message
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.
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 02/02/2014 à 22:43 Membre depuis le 18/06/2001, -26079 message
Call : PpHd appelé(e) sur ce topic...


C'est bien ça ? Ou alors j'y vois toujours pas clair ?
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 02/02/2014 à 22:51 Membre depuis le 27/04/2006, 60479 messages
(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.)
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
Posté le 02/02/2014 à 22:56 Membre depuis le 18/06/2001, -26079 message
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.
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 02/02/2014 à 23:03 Membre depuis le 27/04/2006, 60479 messages
(je pensais que c'était justement ta grande passion, les relogements ? cheeky)
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
Posté le 02/02/2014 à 23:31 Membre depuis le 18/06/2001, -26079 message
Je me suis jamais penché sur les relogements 16 bits ajoutés pour PedroM grin
(sinon, oui, une haine séculaire, presque aussi forte qu'entre la perfide Albion et moi, existe entre les relogements et moi tongue)
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 03/02/2014 à 16:44 Membre depuis le 18/06/2001, -26079 message
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 ?
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 03/02/2014 à 20:20 Membre depuis le 11/06/2001, 19563 messages
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).
Posté le 03/02/2014 à 20:28 Membre depuis le 18/06/2001, -26079 message
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. smile
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 03/02/2014 à 20:35 Membre depuis le 11/06/2001, 19563 messages
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)
Posté le 03/02/2014 à 20:43 Membre depuis le 18/06/2001, -26079 message
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. smile
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 03/02/2014 à 20:57 Membre depuis le 11/06/2001, 19563 messages
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.
Posté le 03/01/2015 à 21:58 Membre depuis le 10/06/2001, 40270 messages
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).
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
Posté le 03/01/2015 à 22:12 Membre depuis le 10/06/2001, 45113 messages
Tiens, salut Kevin !
Bonne année ! cheeky