Opcodes 68000 - Page 1

- S (Size) : taille de l'opérande (00 = octet ; 01 = mot ; 10 = mot double)

- Dans le 68kPM ou 68000UM.

- Les autres bits ne peuvent être que 0 (puisque en-dessous on voit que les cas où il y a des 1 sont utilisés par d'autres modes d'adressage)

- D (Direction) : ça dépend des instructions Pour LSL/LSR, c'est ce bit qui fait la différence entre les deux opcodes, il indique donc le sens du décalage (droite ou gauche). Pour move usp, an et move an, usp, le bit sert à préciser le sens du transfert : usp vers an ou l'inverse.

- Les versions en rose indiquent toujours le mode d'adressage qui est codé selon le tableau de droite de la première page. Tandis que les M en vert sont, là encore, propres à chaque instruction : par exemple pour MOVEP, le M spécifie la direction et la taille du transfert (ie 100 = mot transféré de la mémoire vers les registres).

- Ça dépend encore des instructions, pour SBCD par exemple ce bit permet de faire la différence entre les deux modes d'adressage possibles (dx, dy et -(an), -(am))

Tu codes un assembleur ?

Je parie qu'il veut essayer de faire un assembleur en une passe

! Dans l'IDE, crée un fichier source contenant :asm { #include "monprogrammeasm.asm" };Hey, tu peux coder en assembleur avec GTCEt voilà

Sinon, pour un assembleur ce n'est pas compliqué de le faire fonctionner en une seule passe (peut-être que c'est aussi le cas pour un compilateur C - je n'y ai pas réfléchi). Enfin, de toute façon il faudra que tu repasses quand même boucher certains trous à un moment, mais tu peux tout faire en ne lisant le fichier source qu'une fois, et en mettant les sauts vers les références non encore connues de côté, jusqu'à ce que tu tombes dessus en lisant le fichier, et tu pourras alors compléter le code que tu avais généré.
Par contre, pour gérer un petit préprocesseur avec des macros, ça se complique peut-être...

On n'a plus vraiment une seule passe dans ce cas... Enfin faut voir comment on définit ce mot.

Martial Demolins (./6) :
ouais. Mais quid du portage de GTC pour PedroM ?quid de la taille d'un tel assembleur ?

Quelle idée d'installer des OS alternatifs qui ne sont compatibles avec aucune application. Pourquoi changer d'OS alors qu'on te livre gratuitement un très bon OS avec ta machine ?

Thibaut (./8) :
Pourquoi changer d'OS alors qu'on te livre gratuitement un très bon OS avec ta machine ?

Je parie qu'en proportion une grosse partie du coût vient de l'OS plutôt que du matériel.

Martial : "application", pas "programme"
Fallait pas le déranger pour ça, je transposais des paroles qu'on entend souvent à propos d'une autre situation

ExtendeD : Exactement, un peu comme dans cette autre situation où tout le monde a l'impression que l'OS est offert.

(je sens que ça va partir en couilles, mea culpa)

Oh, alors là, oui, PpHd va bien rigoler
Tu exagères, Thibaut ^^

Thibaut (./8) :
Pourquoi changer d'OS alors qu'on te livre gratuitement un très bon OS avec ta machine ?

t3 news PedroM VS AMS

Il y a un CAS dans PedROM ? Alors là chapeau

Pour info, PedroM est l'OS par défaut de TIEmu sur ma machine, je n'ai pas changé ce défaut. Je ne change que quand je veux tester sur AMS (par exemple, TICT-Explorer). Les demos d'ExtGraph se foutent totalement d'être tournées sous AMS ou sous PedroM.

@Thibaut: si l'application que tu veux ne tourne pas, ou pas bien sur PedroM, rien ne t'empêche de a) implémenter des routines et les contribuer et b) reporter des bugs.
PpHd est plus réactif et plus ouvert que Kevin

Nan mais c'était pour rire hein la remarque de Thibaut

Lionel Debroux (./16) :
PpHd est plus réactif et plus ouvert que Kevin

Je n'ai pas eu cette impression: à chaque fois que j'ai demandé à PpHd de changer quelque chose, il a refusé. Quand il a une idée, il l'implémente et la garde, même si tout le monde lui dit que c'est une mauvaise idée. (Exemple: CALCULATOR qui vaut 255 sur Titanium dans PreOs (je dis bien 255 et pas -1 parce que CALCULATOR a toujours été non signé) contrairement à la définition de TIGCC, TitaniK et Iceberg où la Titanium est considérée comme une TI-89 HW3/HW4 et donc CALCULATOR==0. Ça aurait cassé la compatibilité source C avec tous les programmes qui font if (CALCULATOR) pour détecter les calculatrices à grand écran et aussi avec les programmes codés entre le rajout du support Titanium dans TIGCC et la release de PreOs 0.70, donc TIGCC ne peut plus utiliser CALCULATOR du kernel directement à cause des contraintes de compatibilité antérieure, à la place, nous sommes obligés d'utiliser cette bidouille:

/* PreOs 0.70 says CALCULATOR is -1 on the Titanium. We don't. */
#define CALCULATOR ((signed char)_CALCULATOR[0]>0?_CALCULATOR[0]:0)

.)

PpHd n'a fait aucune difficulté pour les deux ROM_CALLs triviaux que j'ai implémentés pour que TICT-Explorer fonctionne sous PedroM. Il les a intégrés rapidement, et les bugs que j'ai reportés ont vite été corrigés.
Dans ce que tu maintiens (TIGCC tout seul, TIEmu en collaboration), non seulement les contributions ne sont pas intégrées avec une grande vélocité, mais encore, elles sont souvent refusées pour des motifs pas toujours techniques. Par exemple, la dernière en date, le patch qui "ne sert strictement à rien" à tigcc-dasm, sauf à être une brique vers ce que tu m'avais indiqué juste avant, à savoir se débarrasser du désassembleur issu de UAE.

Forcément, tu ne connais pas la spec que Romain m'avait fournie (de manière non formelle, juste en 2-3 phrases par mail ou messages instantanées) pour l'unification des 2 désassembleurs, il a demandé que le désassembleur de la libopcodes ait un mode de désassemblage qui donne entièrement la syntaxe style VTI/A68k utilisée actuellement par le désassembleur de UAE, ça va beaucoup plus loin que juste les % devant les registres, ça touche aussi les histoires de $ vs. 0x etc. Mais de toute façon:
* ce n'est intéressant que pour TiEmu, pas dasm-tigcc et
* je vais en rediscuter avec Romain, parce que AMHA, on a besoin d'une seule syntaxe et c'est celle de l'assembleur (par défaut, pas l'assembleur déprécié et non-libre que nous ne proposons en option que pour la compatibilité antérieure) de TIGCC. J'ai ras le bol des incohérences et je retiens une aberration d'utiliser $ plutôt que 0x pour désigner les chiffres hexadécimaux (d'ailleurs j'ai envie d'aller à la chasse des signes '$' dans TiEmu et les corriger en "0x", il y en a quelques uns).

N'empêche objectivement ça prend moins de place et c'est nettement plus lisible.

Et c'est la syntaxe de plein d'assembleurs. Kevin veut révolutionner le monde ?

Kevin Kofler (./21) :
(par défaut, pas l'assembleur déprécié et non-libre respectant la syntaxe standard que nous ne proposons en option que pour la compatibilité antérieure)

Corrigé.

Je sens qu'il va falloir que j'intègre les sources d'a68k dans PedroM, moi.

Martial Demolins (./25) :
J'y ai pensé à cause de l'incapacité de GNU as de résoudre certains problèmes

A68k ne permet pas de faire ça non plus.

PpHd (./26) :
Je sens qu'il va falloir que j'intègre les sources d'a68k dans PedroM, moi.

Ca poserait pas des problèmes de licence ?