Page 1 sur 2

CMOC pour Thomson sur GitHub

Publié : 14 avr. 2019 15:59
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.

Re: CMOC pour Thomson sur GitHub

Publié : 15 avr. 2019 09:04
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.

Re: CMOC pour Thomson sur GitHub

Publié : 15 avr. 2019 10:47
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.

Re: CMOC pour Thomson sur GitHub

Publié : 15 avr. 2019 10:59
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).

Re: CMOC pour Thomson sur GitHub

Publié : 15 avr. 2019 11:22
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.

Re: CMOC pour Thomson sur GitHub

Publié : 15 avr. 2019 11:32
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 ;)

Re: CMOC pour Thomson sur GitHub

Publié : 15 avr. 2019 11:51
par __sam__
Oui forth c'est bien :) Mais ca dérive trop donc je sors :arrow: []

Re: CMOC pour Thomson sur GitHub

Publié : 16 avr. 2019 11:16
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

Re: CMOC pour Thomson sur GitHub

Publié : 16 avr. 2019 18:49
par __sam__
Que doit contenir cette lib minimale ?

Re: CMOC pour Thomson sur GitHub

Publié : 17 avr. 2019 14:25
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.

Re: CMOC pour Thomson sur GitHub

Publié : 17 avr. 2019 14:32
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

Re: CMOC pour Thomson sur GitHub

Publié : 17 avr. 2019 19:38
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.

Re: CMOC pour Thomson sur GitHub

Publié : 17 avr. 2019 19:40
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).

Re: CMOC pour Thomson sur GitHub

Publié : 17 avr. 2019 20:07
par gilles
c'est une base de travail cohérente, à intégrer partiellement et à optimiser par la suite.

Re: CMOC pour Thomson sur GitHub

Publié : 23 oct. 2020 22:04
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).