Opcodes 68000 - Page 9

GoldenCrystal (./239) :
./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.

Sauf que ce n'est pas toujours vrai, pour movea ce n'est pas une distinction qui a un sens pour le CPU : tu pourrais coder un movea.b, et movea est simplement un move quelconque avec un An en destination. Si c'était ça la vraie raison il faudrait supprimer movea...

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 ^^

Tu vas me faire croire que quelqu'un qui est capable d'écrire un assembleur ne serait pas capable d'assembler cmp si la destination est un registre d'adresse ?

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.

Ben l'admettre en tant que rétrocompatibilité, pourquoi pas : mais l'imposer en tant que seule et unique façon propre, c'est ridicule.

PpHd (./226) :
Bon va falloir que je mette a68k en plus pour preos avec auto-compilation + modification de PedroM pour utilisation de celui de preos.

Tu es censé convertir ta source à GNU as plutôt.

J'ai aussi au moins une raison pour toi: GNU as te permet d'utiliser des différences d'adresses où les labels sont dans des fichiers compilés séparément.

Folco (./229) :
Aujourd'hui, on ne compile plus PedroM avec TIGCC. Kevin, c'est normal ?

J'ai toujours eu besoin de patcher PedroM pour le compiler avec TIGCC (cf. pedrom-ld-tigcc), je commence à avoir l'habitude aussi.

D'ailleurs, je trouve ça fortement ironique qu'il faille un assembleur non-libre pour assembler un OS sous GPL. Folco, n'est-ce pas toi l'extrémiste du libre, au point de préférer BLAG à Fedora? Venant de ta part, c'est particulièrement hypocrite de défendre l'usage de A68k.

Alors pourquoi ne peut-on pas faire de différence de labels entre deux sources (ce qui au passage, oblige à fusionner les sources, même si on aime pas les include "truc.asm") ?

Ce n'est pas un bogue, c'est une fonctionnalité que GNU as a et que A68k n'a pas, tout simplement, il n'a pas été conçu pour permettre ça.

Il y a un problème avec les equate, de mémoire, je ne peux pas utiliser mylib::myfunc, je dois utiliser mylib@00xy à la place. Et tu le sais, on en a parlé dans cette rubrique, mais tu n'as pas voulu mettre sur ta todo.

Probablement parce que ce n'était pas un bogue non plus, mais il faudra que tu me montres exactement la discussion pour que je puisse te répondre.

Autre bug : MULU.L est compilé, peut-être bien aussi les MULS/DIVU/DIVS, ce qui est anormal.

Si je corrige tous ces bogues "accepts-invalid", la moitié des sources existantes pour A68k ne compilent plus (on trouve plein de MOVEQ.W etc. dans les sources parce que A68k a toujours accepté), ce qui serait quand-même gênant pour un assembleur qu'on n'inclut que pour la compatibilité antérieure. Donc il est impossible de corriger ces bogues dans A68k, si tu veux un assembleur qui n'accepte que du valide, utilise GNU as.

Moi j'ai été convaincu par l'argumentation de Pollux dans le débat cmpa/cmp

Kevin Kofler (./242) :
GNU as te permet d'utiliser des différences d'adresses où les labels sont dans des fichiers compilés séparément.

Et il permet d'écrire par exemple (label1-label2)/4 ? Et même dans le cas d'un simple label1-label2, quel est le format de fichier objet qui gère ça (quand un les labels sont dans différents fichiers sources hein) ?

Sasume (./243) :
Et il permet d'écrire par exemple (label1-label2)/4 ?

Seulement si tu n'es pas en mode all-relocs (comme avec A68k), et tu ne peux pas utiliser ça avec des labels dans les fichiers compilés séparément (pour la même raison; la question ne se pose pas avec A68k parce qu'il ne gère même pas label1-label2 avec des labels dans des fichiers compilés séparément). Et cette raison, c'est qu'il y a des relogements positifs et négatifs, mais il n'y a pas de quarts de relogements. Or, en mode all-relocs, ou pour représenter les différences entre labels externes, il faut une paire de relogements (positif+négatif), donc on ne peut pas diviser par 4. (Le mode all-relocs est le mode d'assemblage utilisé pour permettre les optimisations au niveau du linker.)

(Pourquoi faut-il que je répète cette explication sans arrêt? J'ai déjà expliqué ça plusieurs fois dans des forums publics!)

Et même dans le cas d'un simple label1-label2, quel est le format de fichier objet qui gère ça (quand un les labels sont dans différents fichiers sources hein) ?

Extension TIGCC au format COFF. Enfin, plus précisément, le relogement négatif 32 bits est présent dans le standard COFF, mais normalement pas utilisé, les relogements négatifs 16 bits et 8 bits sont des extensions TIGCC.

Que à la limite, le .l est acceptable pour tous, et le .w pour lea et jsr si jamais le mode d'adressage est Abs.W (uniquement), et le .b pour aucun (évidemment )
Après faut voir aussi si tu acceptes jsr.l (xxxx).w (très très moche ) et autres joyeusetés...

Folco (./245) :
Toujours dans la lignée de mes "découvertes". Lea, pea, jmp,jsr et d'autres sont donnés comme "unsized". A votre avis, c'est mauvais d'accepter un jsr.l 0x01234568 ? Le L a exprime bien l'adressage en (xxx).l, non ? Il vous en semble quoi ?

Oui si tu veux être très strict je te conseille de refuser une taille pour lea/jmp/jsr, par contre pour pea le .l est clairement correct : contrairement à lea/jmp/jsr qui modifient des registres d'adresse ou pc et donc qui ont une taille implicite, pea met un longword sur la pile. Mais point de vue rétrocompatibilité il y a des chances que lea.l soit assez courant, et puis c'est pas non plus franchement choquant.

La suggestion de golden m'a l'air un peu bof, normalement on considère les effective address comme des boîtes noires et il n'y a pas vraiment de raison de distinguer entre abs.w et abs.l en dehors de l'effective address elle-même...

Kevin Kofler (./244) :
(Pourquoi faut-il que je répète cette explication sans arrêt? J'ai déjà expliqué ça plusieurs fois dans des forums publics!)

fais une faq

>Pourtant un cmpa sera mis à la place. Pourquoi trouves-tu que c'est pire ? EXG an,dn est interdit également, je veux dire ni plus ni moins, même si c'est 100 fois moins évident pour le codeur, en effet.
J'avais mal compris ce que tu comptais faire. Désolé pour ma remarque.

Kevin Kofler (./242) :
Tu es censé convertir ta source à GNU as plutôt.

Pas envie.

Kevin Kofler (./242) :
J'ai aussi au moins une raison pour toi: GNU as te permet d'utiliser des différences d'adresses où les labels sont dans des fichiers compilés séparément.

Tant qe ca ne supporte pas le quart de relogement, ca ne m'interesse pas.

Kevin Kofler (./242) :
J'ai toujours eu besoin de patcher PedroM pour le compiler avec TIGCC (cf. pedrom-ld-tigcc), je commence à avoir l'habitude aussi.

Et la 0.82 ?

Kevin Kofler (./242) :
D'ailleurs, je trouve ça fortement ironique qu'il faille un assembleur non-libre pour assembler un OS sous GPL.

Pas ma faute si GNU as supporte pas la syntaxe 68000 standard.

C'est à toi de t'adapter aux outils libres, pas l'inverse.

C'est à toi de t'adapter aux outils libres, pas l'inverse.

Quoted
Par son énormité, ce commentaire me fait penser à celui que tu m'as envoyé en privé, dans lequel tu défendais l'utilisation de mesures de filtrage (avec mention explicite de la solution technique du blocage d'IP, pourtant connue comme particulièrement inefficace et injuste) pour empêcher l'accès à un logiciel libre


Puisque c'est un outil libre, il se pourrait aussi que ce soit lui qui adapte les outils libres à ses besoins. C'est une des 4 libertés, rappelle-toi
Liberté qui est déjà utilisée par des membres de la communauté pour divers morceaux de TIGCC, d'ailleurs...

nan mais lol... un outil par définition doit s'adapter au travail, pas l'inverse
On aura tout lu

Lionel Debroux (./252) :
Puisque c'est un outil libre, il se pourrait aussi que ce soit lui qui adapte les outils libres à ses besoins. C'est une des 4 libertés, rappelle-toi

S'il rajoute un mode de compatibilité A68k à GNU as ou nous fait une autre alternative libre à A68k, tant mieux, justement! Le problème, c'est qu'il utilise un assembleur non-libre.

Pen^2 (./253) :
un outil par définition doit s'adapter au travail, pas l'inverse

Dans ton monde des rêves peut-être... Dans la réalité, les outils sont ce qu'ils sont, il faut s'y adapter. Sinon, moi, je veux une voiture qui ne consomme rien, qui peut être utilisée sans permis et qui me téléporte n'importe où au monde en une milliseconde. Vas-y, adapte-moi l'outil au travail.

Kevin Kofler (./255) :
Le problème, c'est qu'il utilise un assembleur non-libre.

une fois bootstrapé on s'en tape non?

Je parle de PpHd et de PedroM. L'assembleur on-calc de Martial ne pourra pas assembler PedroM.

ah oui c'est vrai, pardon.

Il fera peut-être une version PC ?

Euh merde j'avais déjà oublié...

Avec un bon préprocesseur bien adapté, de l'asm ça peut se convertir en C
(J'ai jamais dit que c'était propre par contre, et puis faut quand même réécrire les parties dépendantes de l'OS )

on peut coder en asm pour PC aussi tu sais...

Encore faut-il dénicher un convertisseur 68k->x86

onur (./262) :
on peut coder en asm pour PC aussi tu sais...

Du temps où il n'y avait pas 5000 variantes d'architecture x86 et que la liste des instructions pouvait encore tenir dans un livre de 100 pages (haha) oui, mais maintenant c'est plus trop le cas.
A part ça je vois pas le rapport vu que martial code en asm 68k...

Ben, tu prends une architecture minimum et tu codes pour celle-là, et tu t'en fous des instructions bizarres si tu ne cherches pas à avoir l'optimum en vitesse (ce qui de toute façon n'est pas possible étant donné les nombreux CPUs x86). Et il faut très peu de modifications pour porter de l'ASM x86 en x86_64. (D'ailleurs, il est déjà presque envisageable de faire du x86_64-only de nos jours, presque toutes les nouvelles machines sont 64-bits.)

Kevin Kofler (./265) :
(D'ailleurs, il est déjà presque envisageable de faire du x86_64-only de nos jours, presque toutes les nouvelles machines sont 64-bits.)

Je sens que tu vas t'en donner à coeur joie pour troller, mais tous les OS ne sont pas 64 bits, et même ceux qui le sont n'ont pas toutes leurs libs compatible 64 bits...

Folco, wine.i386 marche très bien sous Fedora x86_64.

Pollux (./266) :
et même ceux qui le sont n'ont pas toutes leurs libs compatible 64 bits...

Dans Fedora, presque tous les paquetages sont compatibles x86_64, les exceptions documentées (normalement toutes sont censées l'être) sont WINE (parce que la version 64 bits est préliminaire et ne gèrera de toute façon jamais les binaires 32 bits, qui sont les plus courants), athcool (ne sert que pour de vieux Athlons 32 bits), Gambas 1 (mais Gambas 2 est disponible), MoscowML et Ikarus (les 3 derniers sont des compilateurs ou interpréteurs rarement utilisés, rien d'autre dans Fedora ne les utilise à ma connaissance). Bref, dire que Fedora "n'a pas toutes ses libs compatible 64 bits", c'est quand-même couper les cheveux en 4.

Kevin Kofler (./269) :
sont WINE (parce que la version 64 bits est préliminaire et ne gèrera de toute façon jamais les binaires 32 bits, qui sont les plus courants)

et si un exe64 a besoin de lancer un exe32 ?