Outils de developpement 68k sous Linux ?

[gotcha]

Hello,

Je suis en train de chercher les outils de développement sous Linux pour programmer ma carte SBC à base de 68008 (https://www.kswichit.com/68008/68008.htm).

Le moniteur de cette carte a été programmé avec IDE68k v3.0 (sous Windows peut-être ?), mais tous les liens que je trouve sont morts (la page de l'auteur Peter J. Fondse n'existe plus). Savez-vous où je peux le trouver. Est-ce que quelqu'un l'a ?
EDIT: en fait, l'auteur de la carte l'a mis en download sur son site: https://www.kswichit.com/68008/ide68k30.zip

J'ai l'impression que la programmation pour 68000 est passée de mode

Pour l'assembleur, j'ai trouvé vasm-m68k qui marche bien. Il me faut maintenant trouver un compilateur C. A priori, gcc supporte la target 68k, mais je n'ai pas encore trouvé les options. LLVM 13 semble aussi supporter le 68k, a voir ...

Si vous développez pour 68k (de préférence sous Linux), je suis preneur de tout conseil / outil.

[Gege34]

Du même auteur que vasm, tu a vbcc.

[6502man]

Pour développer mon Diag pour Amiga 1000 j'ai utilisé EASY68K (Win10) assembleur, émulateur, simulateur ...
Qui est le seul que j'avais trouvé qui me permettais d'exporter un binaire.

[__sam__]

Utilises vbcc (http://sun.hasenbraten.de/vbcc/index.php?view=vbcc0_9f) ou gcc (https://darkdust.net/writings/megadrive/crosscompiler).

[jojo]

Lazarus (Free Pascal) est un IDE et un compilateur multi-plateformes, multi-processeurs et doit pouvoir compiler pour les cpu 68k.
Pour ma part testé avec succès sans changer une ligne de code dans des programmes fonctionnant à la fois sous Windows et sous Linux et avec des processeurs x86, x86_64 et ARM 32 et 64 bits. Il m'a juste fallu insérer quelques directives de compilation et indiquer les bibliothèques à utiliser dans les options de projets pour les différents environnements.

[gotcha]

Merci pour ces infos. Pour l'instant je vais faire une première pour moi: tenter de lancer une application Windows dans Linux avec Wine. Comme le projet de createur de la carte est pour ide68k, je me dis que c'est l'occasion d'essayer. Je ne sais pas pourquoi, mais j'ai un réel blocage à faire du développement sous Windows
EDIT: et ça marche ! Je ne pensais pas qu'utiliser Wine serait si simple.

Ensuite, je pense que je passerai à un pur projet Linux avec un compilateur classique en ligne de commande (comme vasm et vbcc) et cmake.

Hier, j'ai reçu un petit stock de PLD (GAL22V10) et je vais pouvoir m'amuser à (tenter de) changer le mapping mémoire de la carte 68008 comme premier exercice 'hardware'.

[nouvelhermes]

j'ai trouvé cette page au cas où cela pourrait aider
https://www.fxjavadevblog.fr/m68k-cross-compiling/

[gotcha]

@nouvelhermes étant donné que j'ai quelques Atari ST qui dorment chez moi, le coté Atari de cette page peut aussi être utile

[gotcha]

Bon, j'ai un peu avancé coté outillage.

La SBC à base de 68008 avec laquelle je joue actuellement utilise un ancien outil IDE68k v3.0 (SBC: https://www.kswichit.com/68008/68008.htm). Cet outil compile le C et l'assembleur 68000 sous Windows. Il peut générer l’exécutable en format Motorola S-Record (aussi appelé S19), comme attendu par la carte. J'ai réussi a installer et utiliser IDE68k sous Linux (Ubuntu) en utilisant Wine.

Cependant, je préfère utiliser des outils plus classiques et aujourd'hui, j'ai cherché à utiliser la chaine d'outil 'standard' GNU (gcc, gas etc..). J'ai réussi sur un petit exemple à assembler du code assembleur en générant le format S-Record, et aussi à compiler la version C de cet exemple.

La chaine d'outil GNU pour 68000 est disponible sous Linux. Pour ubuntu, c'est:

Code : Tout sélectionner

sudo apt-get install gcc-m68k-linux-gnu

=========
Assembleur
=========

La première chose que je note, c'est que la syntaxe de l'assembleur GNU est bien différente.

Par exemple, mon fichier d'origine a le format suivant:

Code : Tout sélectionner

         org       $400
main     move.l    #$12345678,d0
         move.b    d0,$f0000

L'assembleur correspondant GNU est:

Code : Tout sélectionner

	.text
	.globl	main
main:	move.l    #0x12345678,%d0
        move.b    %d0,(0xf0000)

L'adresse cible n'est pas dans le code, mais sera donnée au moment du link.

Pour assembler mon fichier en S19 à l'adresse voulue (400), on le fait en 2 étapes comme avec les outils modernes (assemblage et link):

Code : Tout sélectionner

m68k-linux-gnu-as -m68000 -o gnu-test.o  gnu-test.asm
m68k-linux-gnu-ld --oformat=srec -o gnu-test.s19 -N -e main -Ttext 400 gnu-test.o

=========
C
=========

Si on veut partir du C, par exemple pour le programme équivalent suivant:

Code : Tout sélectionner

void main() {
  int i = 0x12345678;
  char *p=(char*)0xf0000;
  *p = i;
}

On ferra alors:

Code : Tout sélectionner

m68k-linux-gnu-gcc -m68000 -o test.o test.c
m68k-linux-gnu-ld --oformat=srec -o test.s19 -N -e main -Ttext 400 test.o

[__sam__]

C'est de la syntaxe MIT qui a été inventé là bas (au M.I.T). Ca été utilisé partout dans gcc en opposition à la syntaxe officielle du fondeur (Motorola) dite syntaxe MOT.

En général il n'y a pas de "." accolé au mnémonique de l'opération pour indiquer sa taille (ex: addb au lieu de add.b pour une addition d'octets). Il y a des "%" dans les registres, des ":" pour spécifier la taille des registres d'index dans les adressages, l'utilisation de "'@" pour dire adressage étendu (par registres), et un changement de position des offsets constants (labels) dans les adresses (exemple: addw %d1,%a0@(label,%d0:w:2) versus add.w d1, label(a0,d0.w*2) ).

Il ne faut pas oublier non plus qu'en syntaxe MIT les sauts s'écrivent jb<cc> au lieu de b<cc> (exemple: jbcc _label vs bcc.w _label), sauf que là c'est un avantage car le jbsr peut faire un bsr.s ou bsr, ou même un jsr en automatiquement en fonction l'avantage de l'adresse relative 8/16 bits ou absolue 32bits.

Récemment (2003 quand même), il était question de laisser tomber la syntaxe MIT dans gcc (dans gas en fait). Et j'ai pu observer qu'avec gcc6 la syntaxe ASM était du pur Motorola. Enfin !

En effet j'avais du, à l'époque, me coltiner les deux syntaxes Mit et Mot pour mon outil APurify quand il a été intégré dans la baseline de gcc270 pour Amiga.

[gotcha]

Ma version de gcc 68k date de 2019 (9.x).
Finalement, cela veut dire que c'est plutôt IDE68k qui ne suit pas exactement la syntaxe officielle de Motorola (registres sans %, hexadécimal avec $ etc...).

[__sam__]

Ou alors la distinction MIT/MOT est peut-être toujours d'actualité, et c'est le gcc6 que je connais qui est l'exception (car faite par un Amigaiste )

Sinon tu n'as pas essayé avec EASY68K. C'est un environnement de compilation, simulation tout intégré. Il peut produire des binaire au format S-RECORD (motorola), et d'après cette capture écran, c'est de l'assembleur Motorola:


Ok, c'est du windows, mais c'est reporter tourner sous Wine je crois.

[gotcha]

Donc la syntaxe '%d0' pour les registres générée par mon gcc 9.x n'est pas la syntaxe officielle ?

Y a t'il un endroit où la syntaxe 'officielle' de Motorola est définie ? Quel a été l'outil ou la doc de Motorola qui a défini cette syntaxe 'officielle' ?

L'avantage de gcc, même s'il ne suit pas la syntaxe officielle, c'est qu'il est facile de combiner du C et de l'assembleur. Easy68K ne fait que de l'assembleur et pour des projets plus complexes, avoir des parties en C est plus productif. Dans mon cas, je veux faire un petit système multi-processus pour ma SBC et une bonne partie sera en C.

Je vais regarder aussi du coté de Clang/LLVM car à priori, il y a eu de nouvelle choses pour le 68000 dans LLVM 13.

[__sam__]

Donc la syntaxe '%d0' pour les registres générée par mon gcc 9.x n'est pas la syntaxe officielle ?

Pas celle de motorola.

Y a t'il un endroit où la syntaxe 'officielle' de Motorola est définie ? Quel a été l'outil ou la doc de Motorola qui a défini cette syntaxe 'officielle' ?

Ben j'ai donné le lien plus haut par rapport à la syntaxe "MOT". De toute façon la syntaxe est décrite dans la doc de ton environnement, par exemple >>ici<<.

L'avantage de gcc, même s'il ne suit pas la syntaxe officielle, c'est qu'il est facile de combiner du C et de l'assembleur.

Je ne dirais pas ca. Le passage des arguments dans les asm volatile() sont un truc que seul un grand malade a pu inventer pour son propre usage. On se demande encore comment ceci a pu être sorti dans la nature:

Code : Tout sélectionner

#if defined(__GNUC__) && defined(__mc68000__)
		asm volatile("move%.w (%1)+,%0" : "=d" (pc) : "a" (argv));
		asm volatile("mulu %1,%0" : "+d" (pc) : "m" (*(2+(char*)&story_scaler)));
#else
		pc = (( short ) *argv++) * (short)story_scaler;
#endif

Avec VBCC (aussi un compilo 68k portable) c'est beaucoup plus simple!

Easy68K ne fait que de l'assembleur et pour des projets plus complexes, avoir des parties en C est plus productif. Dans mon cas, je veux faire un petit système multi-processus pour ma SBC et une bonne partie sera en C.

VBCC target les SBC de toute taille (dont les 8 bits). Bon après c'est pas un IDE complet. Juste un compilateur, assembleur et linker en ligne de commande. Mais rien n'empêche d'utiliser un truc comme Eclipse par dessus.

Je vais regarder aussi du coté de Clang/LLVM car à priori, il y a eu de nouvelle choses pour le 68000 dans LLVM 13.

Il y a aussi les IDE de pro comme CodeWarior. A la base c'est payant, mais la version "Special Edition" est "free", cf: https://community.nxp.com/t5/Classic-Le ... m-p/487152

[hlide]

Alors, ayant essayé à plusieurs de ces compilateurs avec leur différentes façons d'insérer des instructions complexes (il n'y a pas que le 68K sous gcc), alors oui au début j'étais perplexe devant la "complexité" d'un asm sous gcc. Mais après m'être bien renseigné sur les options de passage d'argument, j'ai pu constater la puissance de ce système qui m'a permis de générer du code assembleur bien intégré qui n'a jamais été le fort de la directive asm des autres compilateurs de l'époque. Donc oui, j'en comprends l'utilité et à quel point ça permet de couvrir beaucoup de cas. Après il faut reconnaître que si l'on n'en fait pas très souvent, on a vite fait d'oublier comment cela marche. C'est très puissant mais pas à la portée du néophyte.