CMOC pour Thomson sur GitHub

Cette catégorie traite de développements récents pour nos vieilles machines, applications, jeux ou démos... Amis programmeurs, c'est ici que vous pourrez enfin devenir célèbres!

Modérateurs : Papy.G, fneck, Carl

Linzino
Messages : 69
Inscription : 26 août 2017 02:40

CMOC pour Thomson sur GitHub

Message par Linzino »

Voila ma petite librairie pour compiler du C avec CMOC pour les Thomsons et Olivetti Prodest PC128:

https://github.com/Fabrizio-Caruso/CMOC-for-Thomson

Dans le repo, vous trouvez tout ce qu'il faut.
J'ai aussi mis un petit exemple.
C'est juste une librairie initiale pour montrer qu'on peut utiliser CMOC pour coder pour les Thomsons.

J'utilise une version de cette librairie aussi dans mon projet Cross Chase.
Avatar de l’utilisateur
gilles
Messages : 2779
Inscription : 07 août 2008 13:44
Localisation : Nantes
Contact :

Re: CMOC pour Thomson sur GitHub

Message par gilles »

j'irai regarder et tester tout ca, pour ma part j'utilise un C réduit beaucoup plus ancien http://trac.alternative-system.com/brow ... 8-sdk/mc09

Il n'est pas parfait mais avec un peu d'expérience c'est un bon compromis pour mixer C et assembleur.
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: CMOC pour Thomson sur GitHub

Message par __sam__ »

J'ai lu la doc de CMOC au niveau des "supported features" du C. C'est très intéressant. La possibilité de mixer C et ASM aussi, ainsi que la programmation modulaire (plusieurs *.o).

Le seul reproche que j'ai est que le code est relogeable, ce qui introduit une très forte pénalité dans la taille et la vitesse du programme (JSR $nnnn->8cycles vs JSR $nnnn,PCR (ce qui est compilé quand il y a un jsr label en asm)->12cycles : 50% plus lent). La relogeabilité a du sens pour les machines avec OS ou des trucs en ROM, mais sur Thomson on s'en fiche plutôt de pouvoir déplacer le code en mémoire. Le code est supposé arriver toujours à l'adresse réservé par l'instruction CLEAR du basic.
Dernière modification par __sam__ le 15 avr. 2019 11:12, modifié 1 fois.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Avatar de l’utilisateur
gilles
Messages : 2779
Inscription : 07 août 2008 13:44
Localisation : Nantes
Contact :

Re: CMOC pour Thomson sur GitHub

Message par gilles »

mc09 fait du LBSR pour l'appel de fonction, c'est relogeable aussi mais c'est moins pire (9 cycles si les cycles de c6809 sont corrects). Par contre il n'y a pas d'optim BSR/LBSR (point discuté ailleurs).
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: CMOC pour Thomson sur GitHub

Message par __sam__ »

Oui LBSR mieux que d'utiliser "$nnnn,PCR", mais ce dernier est partout utilisé lors des accès aux globales. LDD $nnnn-->6 cycles vs LDD $nnnn,PCR-->10 cycles: 66% plus lent :( C'est vraiment le seul reproche que j'aurais à faire à ce compilo après la lecture du manuel.

:idea: Ce que j'aimerais aussi perso dans un env C sur thomson est l'usage transparent de bank-switching pour le code et les données (comme en Basic) car c'est un peu dommage d'avoir des machines avec 256 voire 512ko de ram et d'être coincé à 28ko max de ram+code. J'y ai réfléchit et ca ne me semble pas être un problème facile. La solution universelle est en fait de non pas générer du code ASM, mais du p-code(bytecode) pour une machine virtuelle hyper optimisée qui verrait elle toute cette mémoire de façon contigüe (certains langages Pascal font cela). Ca ne sera pas toujours rapide, mais accèder à toute la mémoire permet de manipuler de plus gros tableaux ou chaines de caractères.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Avatar de l’utilisateur
gilles
Messages : 2779
Inscription : 07 août 2008 13:44
Localisation : Nantes
Contact :

Re: CMOC pour Thomson sur GitHub

Message par gilles »

si tu veux faire quelquechose de simple et rapide et qui pouvait déjà être envisagé à l'époque de sortie du TO8 tu peux aussi faire du forth avec une implémentation de toute la ram paginée. sinon à partir de mc09 on peut envisager qu'une adresse de fonction est en fait composée d'un numéro de banque + une adresse, ce n'est pas très différent du code 8088... mais on dérive totalement ;)
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: CMOC pour Thomson sur GitHub

Message par __sam__ »

Oui forth c'est bien :) Mais ca dérive trop donc je sors :arrow: []
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Linzino
Messages : 69
Inscription : 26 août 2017 02:40

Re: CMOC pour Thomson sur GitHub

Message par Linzino »

Je ne suis pas du tout un expert en Assembleur 6809 et je cherche quelqu'un qui pourrait m'aider à:

1. integrer une lib minimale dans la prochain version de CMOC (l'auteur est d'accord)
2. rajouter des routines optimisées dans la lib minimale
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: CMOC pour Thomson sur GitHub

Message par __sam__ »

Que doit contenir cette lib minimale ?
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Linzino
Messages : 69
Inscription : 26 août 2017 02:40

Re: CMOC pour Thomson sur GitHub

Message par Linzino »

Une librairie tres minimale serait un bon sous-ensemble de stdlib. Il faudrait que cette lib soit buildée quand on compile CMOC. Donc il fadrait modifier le fichier crt.asm et d'autres pour faire en sort que CMOC gère deux nouveaux targets (thomson_m and thomson_t).

Une librairie moins minimale devrait contenir stdlib et avoir un minimum des routines pour gérer des graphismes simples et des effets sonores simples. Il faudrait toujours que cette lib soit buildée à la compilation de CMOC.
Avatar de l’utilisateur
gilles
Messages : 2779
Inscription : 07 août 2008 13:44
Localisation : Nantes
Contact :

Re: CMOC pour Thomson sur GitHub

Message par gilles »

il y avait une mini stdlib faite par Eric Botcazou lors de ses tests gcc il me semble.
ici
https://web.archive.org/web/20160317220 ... ement.html
Linzino
Messages : 69
Inscription : 26 août 2017 02:40

Re: CMOC pour Thomson sur GitHub

Message par Linzino »

@gilles, merci!
Par contre le plus grand problème pour moi n'est pas l'écriture des routines mais plutot leur integration dans le compilateur CMOC.
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: CMOC pour Thomson sur GitHub

Message par __sam__ »

Cette libc est parfois sous-optimale (euclid.s, mulhi3.s)... Mais son problème pour CMOC est qu'elle est exclusive aux TO (et fortement entachée de glue GCC).
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Avatar de l’utilisateur
gilles
Messages : 2779
Inscription : 07 août 2008 13:44
Localisation : Nantes
Contact :

Re: CMOC pour Thomson sur GitHub

Message par gilles »

c'est une base de travail cohérente, à intégrer partiellement et à optimiser par la suite.
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: CMOC pour Thomson sur GitHub

Message par Neotenien »

__sam__ a écrit : 15 avr. 2019 11:22 Oui LBSR mieux que d'utiliser "$nnnn,PCR", mais ce dernier est partout utilisé lors des accès aux globales. LDD $nnnn-->6 cycles vs LDD $nnnn,PCR-->10 cycles: 66% plus lent :( C'est vraiment le seul reproche que j'aurais à faire à ce compilo après la lecture du manuel.

:idea: Ce que j'aimerais aussi perso dans un env C sur thomson est l'usage transparent de bank-switching pour le code et les données (comme en Basic) car c'est un peu dommage d'avoir des machines avec 256 voire 512ko de ram et d'être coincé à 28ko max de ram+code. J'y ai réfléchit et ca ne me semble pas être un problème facile. La solution universelle est en fait de non pas générer du code ASM, mais du p-code(bytecode) pour une machine virtuelle hyper optimisée qui verrait elle toute cette mémoire de façon contigüe (certains langages Pascal font cela). Ca ne sera pas toujours rapide, mais accéder à toute la mémoire permet de manipuler de plus gros tableaux ou chaines de caractères.
Et comment il fait le Basic 512 qui est capable d'exécuter même plus de 80 kO de code ?
Est ce que le gate Array Mode Page ne permet pas d'accéder à la RAM directement en l'adressant physiquement ? (cf "manuel technique des TO8, TO9, TO9+" traitant du gate array) avec le bit 4 (à 1) du registre système 1 (A7E7/E7E7) et les bits D4-D0 de A7E5/E7E5... PS, on peut utiliser + que 28 KO avec le gate Array Mode page, puisqu'on peut allouer les banques RAM dans l'espace cartouche (16 kO), 12kO du système (banque 1) et l'espace A000-DFFF, ce qui fait 44 kO (hors RAM vidéo sur lequel on peut aussi travailler directement).

J'avoue que c'est un problème cette gestion de la RAM limité à la gestion virtuelle, c'est dû au fait que le MC est un 8-16 bits, mais apparemment il fait mieux que les 6502 et autres Z80... qui eux sont 8 bits (en terme de registre).
Répondre