Opcodes 68000 - Page 8

Et c'est quoi ces signes dollar? Ne me dis pas que tu utilises un assembleur obsolète pour ça!

quand il aura bootstrappé ce sera plus un assembleur obsolète

Et la compatibilité avec GNU as sur PC, tu t'en fous? AMHA l'assembleur devrait utiliser la syntaxe GNU.

L'assembleur GNU n'est pas une référence, ce n'est même pas la syntaxe définie par le constructeur...
C'est GNU as qui devrait se rendre compatible avec les syntaxes "normales", et pas l'inverse...

oui c'est super connu ça

je rigoooooooole

Folco (./215) :
J'hallucine de voir comment tu casses de dont tu es mainteneur.

C'est le premier logiciel que j'ai maintenu dans TIGCC, mais ça fait longtemps que je ne m'y intéresse plus vraiment (parce que GNU as, qui est libre contrairement à A68k, fait tout ce qu'il fait et plus), il n'y aura probablement plus aucune nouvelle fonctionnalité dans A68k, je suis déjà content si j'arrive à corriger les bogues qu'on me reporte. Et A68k sera viré bientôt de TIGCC, je voulais faire un mode de compatibilité A68k dans GNU as, mais c'est compliqué vu toutes les bizarreries de syntaxe de A68k (genre l'indentation qui change l'interprétation), donc il se peut que je vais tout simplement virer A68k sans remplacement et qu'il faudra le télécharger séparément (dans une archive nommée "dernière version, distribuée telle quelle, non maintenue" et plus jamais mise à jour).

Folco (./215) :
Sinon, je fais comme toi. La sphère asm 68k est déjà très réduite, alors si je propose de la syntaxe GNU as pour un soft PedroM-only, bonjour la misère.

Comme moi comment? Tous mes outils de désassemblage (TiEmu+GDB, dasm-tigcc) utilisent la syntaxe GNU as, TIGCC ne proposera peut-être bientôt aussi plus que cette syntaxe (et même si j'arrive à continuer à la supporter, la syntaxe A68k ne sera qu'un mode de compatibilité déconseillé). TIGCC lui-même n'utilise que du GNU as. (Par exemple, j'ai porté les routines de désassemblage du pstarter, Samuel Stearley nous avait pondu du A68k, j'ai tout comverti en GNU as.) Et si je fais des mises à jour importantes pour mes logiciels en assembleur, ils seront portés eux aussi.

Qui se sent de faire ce mode de compatibilité de GNU as avec la syntaxe A68k pour le TIGCC non officiel, ainsi que, pourquoi pas, pour un TIEmu+GDB non officiel ?

D'après mes souvenirs, cmpi permet d'écrire cmpi.w #machin, d(an) (par exemple), alors qu'avec cmp tu ne peux pas.

Ces bogues ne sont pas "ultra-connus" vu que je n'ai aucune idée de quoi tu parles, je n'ai aucun bogue de A68k dans mon todo.

Folco (./217) :
Tiens, saviez-vous que EXG an,dn n'est pas permis, il faut écrire EXG dn,an ?

Je laisse ce genre de détails sordides à l'assembleur.

Kevin Kofler (./220) :
C'est le premier logiciel que j'ai maintenu dans TIGCC, mais ça fait longtemps que je ne m'y intéresse plus vraiment (parce que GNU as, qui est libre contrairement à A68k, fait tout ce qu'il fait et plus), il n'y aura probablement plus aucune nouvelle fonctionnalité dans A68k, je suis déjà content si j'arrive à corriger les bogues qu'on me reporte. Et A68k sera viré bientôt de TIGCC, je voulais faire un mode de compatibilité A68k dans GNU as, mais c'est compliqué vu toutes les bizarreries de syntaxe de A68k (genre l'indentation qui change l'interprétation), donc il se peut que je vais tout simplement virer A68k sans remplacement et qu'il faudra le télécharger séparément (dans une archive nommée "dernière version, distribuée telle quelle, non maintenue" et plus jamais mise à jour).

Bon va falloir que je mette a68k en plus pour preos avec auto-compilation + modification de PedroM pour utilisation de celui de preos.
Je commence à avoir l'habitude.

Kevin Kofler (./225) :
Ces bogues ne sont pas "ultra-connus" vu que je n'ai aucune idée de quoi tu parles, je n'ai aucun bogue de A68k dans mon todo.

Technique classique.

Folco: c'est ton projet, fais ce que tu veux

Tiens, saviez-vous que EXG an,dn n'est pas permis, il faut écrire EXG dn,an ?

Non, je ne savais pas

Je viens de tester ce que fait gas avec:
asm volatile("
exg %d0,%d1
exg %d1,%d0

exg %a0,%d0
exg %d0,%a0

exg %a0,%a1
exg %a1,%a0
");

parce que l'impossibilité d'écrire exg an,dn aurait pu être un problème pour la macro suivante d'ExtGraph:
#define EXT_XCHG(a, b) asm volatile ("exg %0,%1" : "=da" (a), "=da" (b) : "0" (a), "1" (b) : "cc")

gas produit:
exg d0,d1
exg d1,d0

exg d0,a0
exg d0,a0

exg a0,a1
exg a1,a0


Autrement dit, il fait quelque chose de correct avec ce qui doit être une faute courante de programmation. A la différence d'A68k avec moveq.w.
Mais je préfère quand même nettement, à la lecture dans le debugger, la syntaxe A68k, à la fois parce qu'il n'y a pas de % et parce que les nombres sont affichés en hexa...


Au passage, PpHd: est-ce que je t'ai envoyé les patches à ld-tigcc pour donner un timestamp correct aux OS (et aux FlashApps, d'ailleurs) ?

>Au passage, PpHd: est-ce que je t'ai envoyé les patches à ld-tigcc pour donner un timestamp correct aux OS (et aux FlashApps, d'ailleurs) ?
Non

>Je suis partisan d'un assembleur intolérant, qui ne sache pas assembler du code faux. Mais j'ai mis une option +/-force-strict-instructions, et il y a un flag pour les adressages genre EXG an,dn, ou encore cmp.w d0,a0. Mais j'aime pas ça pour autant, je suis juste obligé de le faire en pratique.
Autant pour exg dn,an ca ne porte à aucune conséquence, autant pour cmp.w d0,a0 c'est faux : il ne faut pas l'accepter.

> Aujourd'hui, on ne compile plus PedroM avec TIGCC. Kevin, c'est normal ?
On utilise toujours cc1
Parce qu'autrement.

Au passage, PpHd: est-ce que je t'ai envoyé les patches à ld-tigcc pour donner un timestamp correct aux OS (et aux FlashApps, d'ailleurs) ?

Non

Fait.

C'est ridicule de dire que cmp est incorrect et que cmpa est correct : moi je prends la position inverse, les instructions style cmpa & co sont complètement inutiles et induisent en erreur dans certains cas, donc j'utilise uniquement cmp/add/addq... Pareil pour cmpi, je ne m'en sers jamais cela dit là c'est plus une question de goût parce que ça n'induit pas en erreur ; et puis ça peut même être utile pour comprendre pourquoi cmp.w #imm,<ea> est accepté alors que cmp.w <ea>,<ea2> ne l'est pas, autrement dit dans certains cas c'est réellement une instruction différente (cmpa en revanche ne permet pas de mieux comprendre les choses).

Folco (./232) :
Pollux -> t'as une solution mieux à me proposer pour les modes d'adressages ? c'est bien de dire que ce que j'ai fait est nul, mais comment faire mieux ? J'ai déjà modifié mes flags de longueurs (SIZE_B, SIZE_W, SIZE_L, SIZE_BW, SIZE_WL, SIZE_BL, SIZE_BWL), c'est beaucoup plus lisible.

Ben ce que j'ai proposé ça te va pas ? Dans GTC il y a un #define pour AM_AN_IND|AM_AN_INC|AM_AN_DEC|AM_X_AN|AM_X_AN_XN|AM_XW|AM_XL (que tu pourrais appeler AM_MEM), de même il y a AM_DST = AM_DREG|AM_AREG|AM_MEM, AM_DST2 = AM_DREG|AM_MEM, AM_SRC = AM_DST|AM_PCREL|AM_IMM...
Bref, le but est d'éviter de répéter sur 50 lignes différentes le même ensemble de flags illisibles et plutôt le regrouper dans un seul #define.

Folco (./234) :
Ok, merci, ça sonne mieux en effet.

Quant au coup des cmp/a/i/m, je suis pas d'accord avec toi, pour deux raisons :
- cmpm et cmpa n'ont aucun équivalent,
- c'est à nous de nous plier au CPU, pas l'inverse.

- oui pour cmpm, c'est une instruction assez spéciale donc je vois pas d'inconvénient à la garder telle quelle
- non pour cmpa : c'est juste une convention, l'ensemble des <ea> pour lequel cmpd <ea>,dn et cmpa <ea>,an est valide est le même, donc je vois aucune raison de distinguer suivant la destination : tu peux t'amuser à appeler l'un cmp et l'autre cmpa, mais c'est tout aussi raisonnable d'appeler les deux cmp
- je vois pas où j'ai dit le contraire

Il y a une différence majeure entre cmp et cmpa: cmpa ne fonctionne pas en .b !
(Et puis après c'est aussi du au fait que pour les autres instructions ALU dont la destination est un registre d'adresse (adda et suba) les flag ne sont pas modifiés, et vu que tout est construit sur le même modèle... )

GoldenCrystal (./236) :
Il y a une différence majeure entre cmp et cmpa: cmpa ne fonctionne pas en .b !

Non, cmpa n'est pas le bon critère : le vrai critère c'est qu'aucune instruction ayant un An pour opérande ne fonctionnera en .b... Par exemple cmp.b an,dn ou bien cmpi.b #42,an n'existent pas, alors que cmp.b et cmpi.b existent.

GoldenCrystal (./236) :
(Et puis après c'est aussi du au fait que pour les autres instructions ALU dont la destination est un registre d'adresse (adda et suba) les flag ne sont pas modifiés, et vu que tout est construit sur le même modèle... )

Pareil, adda n'est pas le bon critère : addq ne modifie pas les flags non plus si la destination est un registre d'adresse. Et c'est précisément ça le bon critère : quand la destination est un registre d'adresse, les flags ne sont jamais modifiés (sauf pour les instructions de comparaison elles-même).


Bref, comme tu peux le voir toutes ces instructions en *a donnent des fausses intuitions, quelqu'un qui est habitué à lire du code avec des adda.w ne se rendra pas forcément compte que addq.w #4,an modifie tous les 32 bits du registre même si ça n'est pas une instruction en *a.

./237> Peut-être que c'est le critère humain, mais le critère au niveau du CPU est comme je le décris, et c'est beaucoup mieux pensé (et addq/subq n'est pas un cas spécial, le cpu ignore tout simplement le champ S lorsque la destination est un registre d'adresse, ce qui est facile vu qu'il n'y a aucune extension de taille à faire, en revanche c'est effectivement ambigu que l'instruction modifie ou pas les flags selon la destination... ^^)
Car là ou avec un CMP générique tu devrais faire des tests au niveau du CPU pour vérifier la validité de l'instruction, ici tu n'as même pas à le faire, c'est directement impossible de coder un cmp.b <ea>, An.
Après c'est sur qu'au niveau assembleur résultant il aurait été mieux de cacher les détails d'implémentation, mais il faut bien que tu puisses assembler tes instructions correctement donc il faut faire la distinction quelque part ^^
Moi ça ne me choque pas qu'un assembleur convertisse automatiquement les <ALU> <ea>,<ea> en <ALU>[A|I] <ea>,<ea>, c'est même ce que j'aurai fais si j'avais codé mon assembleur, mais que deux opcodes (même si identiques au niveau humain, et encore ^^) différents soient nommés différemment me semble aussi assez logique.

Folco (./238) :
c'est bien ça la différence entre le bon codeur et le mauvais codeur hein

Le bon codeur c'est celui qui s'est rendu compte à quel point les conventions qu'il utilise étaient illogiques et bourrées de pièges, mais qui continue à les imposer pour "rentabiliser" sa connaissance des pièges ?