Compilateur TURBO BASIC pour Alice 32-90

[David.G]

Bonjour,

Je songe à coder un compilateur BASIC pour Alice 32 & 90.

Il génèrera donc un binaire (programme en langage machine) en compilant vos programmes BASIC.

Je voudrais donc savoir combien de personnes souhaiteraient utiliser un tel programme ?

Je pourrai le mettre en open source si certains veulent l'améliorer ou participer, voire même le porter sur d'autres micros.



[

[kirion]

moi ça m'intéresse fortement. l'idée open source est très bonne également.
je suppose que tu ne vas pas tout écrire from scratch et que tu vas utiliser un compilateur basic existant? lequel ?
ca sera en C je suppose ?

[David.G]

@kirion : Salut,

Oui je vais tout coder à partir de zéro, sinon ça n'a aucun intérêt. En langage assembleur 6803 uniquement et sur la vraie machine avec un lecteur de cassette pour le moment.

Pas besoin d'aller voir un compilateur existant, ni de faire ça en C. Utiliser un langage compilé pour créer un compilateur, ce serait absurde pour moi.

Comme on dit en Finlande quand il fait -30 : "Il n'y a pas de temps froid. Il n'y a que des vêtements inadaptés".

Et comme on dit à Yakoutsk ( Дьокуускай ) en Sibérie quand il fait -70 :
" Il n'y a pas de mauvais temps. Juste des paysages magnifiques."

[Leraptor06]

Bravo c'est un beau projet, j'espere que tu nous partagera tes avancés. A bientot.

[David.G]

@Leraptor06 : Pour les bravos, on attendra que ce soit fait. Bon, j'ai fait la jaquette et j'ai trouvé le nom du soft déjà, c'est pas mal.

Oui, je mettrai à disposition le code source ici et sur Github, il y a des gens bien plus avancés que moi vu que je ne connais pas cet ordinateur.

Une fois la structure de base en place, c'est très simple à porter pour un 6502 ou un Z80.

L'idée est simple : On va chercher le programme BASIC dans la RAM, on génère la même chose en langage machine via un programme écrit en langage d'assemblage et on essaie d'être le moins redondant possible pour générer le programme le plus court possible.

Plusieurs PRINT "ICI LE TEXTE" utiliseront toujours la même routine (principe du GOSUB ou fonction en JS) pour éviter de réécrire plusieurs fois du code identique. C'est l'idée.

[David.G]

Je suis en train de me coder en Javascript un SIMULATEUR ALICE 90 (PAS UN EMULATEUR)

et je programme la mémoire de l'Alice virtuel uniquement en binaire.

Voici la bestiole, inspirée de l'Altair 8800 :

[David.G]

Bon, pour commencer, je dois trouver où se trouve le BASIC en mémoire vive (RAM).
Les instructions du BASIC (REM, PRINT,FOR, NEXT, etc.) sont encodées sous forme de TOKEN et chacune correspond à un chiffre.

Ce sera donc facile de lire la mémoire, de comprendre le programme BASIC et de le réécrire en langage machine.
Je ne connais pas le 6803, mais j'ai survolé le Fagot-Baraly et ça me semble pas sorcier.

Comme je ne connais pas l'Alice, je dois trouver où se trouve le programme BASIC en RAM.

On va donc écrire un sniffer en BASIC : Il va rechercher une chaîne de caractères précise et me donner l'emplacement exact.
Il va m'afficher le contenu de la mémoire et stoppera dès qu'il trouvera "TO". Il n'y a que 65536 adresses donc ça ira.
Je me mets en mode CLS81 monochrome pour obtenir un effet Matrix. Puis je me bois un chocolat chaud en regardant le spectacle.

10 REM TOTO
20 FOR I=0 TO 65535
25 PRINT I, PEEK(I),CHR$(PEEK(I))
30 IF PEEK(I)=84 AND PEEK(I+1)=79 THEN END
40 NEXT I

Voilà, TOTO se trouve en 13132. Je vais pouvoir commencer à identifier chaque TOKEN, écrire un 10 PRINT "BONJOUR",
aller le lire avec mon programme en assembleur et le recoder en langage machine pour en faire un exécutable binaire.
J'aurai ainsi COMPILÉ ma première ligne de BASIC ! Hourra !

[Carl]

Tu devrais trouver des information à propos du CPU, ROM...

ici :

ROM Alice 32 Commentée par SEILEBOST : http://alice32.free.fr/documentation/index.html

le thread de discussion à propos de la ROM, ici : viewtopic.php?p=157798#p157798

le WIKI : https://alice.system-cfg.com/

Carl

[David.G]

Merci beaucoup Carl, je vais regarder tout ça.

[Fool-DupleX]

Aucun rapport donc avec le turbo-basic de Borland.

[David.G]

Ligne de BASIC :

10 REM ABCD

Exploration de la mémoire vive :

Mémoire RAM : (paire adresse/valeur)

13126 : 51 (51 x 256 + 81 = 13137 = ligne suivante)
13127 : 81 (octet de poids faible)
13128 : 00 (octet de poids fort) 0 x 256 + 10 = 10
13129 : 10 (octet de poids faible) = numéro de ligne
13130 : 131 REM (Token)
13131 : 32 Espace
13132 : 65 A
13133 : 66 B
13134 : 67 C
13135 : 68 D
13136 : 00 Fin de ligne
13137 : Ligne suivante

Quand le compilateur voit cette ligne de Basic, il voit que c'est un REM et il l'ignore, tout simplement
et passe en 13137 analyser la ligne suivante.

[hlide]

Et si le REM contenait une suite d'octet comprenant du langage machine que la suite des lignes BASIC appellerait via un EXEC (ou équivalent) ?

[David.G]

@hlide : Oh! Remarque tout à fait pertinente ! Merci de ta contribution !

Je ferai donc en sorte que si le compilateur trouve un EXEC appelant une adresse dans la zone du programme BASIC,
je récupère les octets de la ligne REM et je les insére dans le binaire en tant que routine,
sinon le REM est ignoré.

Cette même routine en langage machine cachée dans le REM pourrait être appelée depuis un autre programme en langage machine,
donc je ne vais pas trop complexifier le compilateur au début, faisons simple pour les programmes écrit en BASIC d'abord,
mais je garde ça sous le coude pour ce deuxième cas ! (Je ne sais pas si il existe sur Alice mais tout est possible)

Purée, c'est avec ce genre de remarque hlide, qu'on va le faire avancer ce compilateur !

Et prouver qu'on peut faire des trucs vraiment sympas avec une machine 8bits.

Je suis intrigué par les zéros qui terminent chaque ligne de BASIC : sont-ils nécessaires vu que le début de la ligne suivante est indiqué sur 2 octets (adresse 16 bits donc codée sur 2 octets).

Si l'ordi avait mis la valeur 80 en 13127, la ligne suivante aurait pu démarrer en 13136 et on gagnait un octet non ?

Je n'ai pas calculé le nombre maximum de ligne qu'on peut entrer dans les 32 Ko de mémoire en général,
mais cela ferait gagner 500 octets sur 500 lignes, pas négligeable sur une machine 8 bits.

Mais à ce stade je dis certainement n'importe quoi car je ne connais pas encore la machine ni l'assembleur.

Les amis, si vous êtes débutants comme moi, codez un compilateur : on apprends plein de choses sur l'ordinateur.

[Mokona]

Je suis intrigué par les zéros qui terminent chaque ligne de BASIC : sont-ils nécessaires vu que le début de la ligne suivante est indiqué sur 2 octets (adresse 16 bits donc codée sur 2 octets).

Oui. L'interpréteur se sert du chainage pour trouver une ligne en particulier (en cas de GOTO ou GOSUB, il repart du début du programme et parcours la chaine pour trouver la bonne ligne, c'est la raison pour laquelle il est parfois conseillé de mettre les routines les plus utilisées en début de programme). Et l'interpréteur se sert du zéro pour indiquer la fin de ligne lors de l'exécution.

En effet, il serait possible d'enlever ce zéro et de stocker l'adresse de la prochaine ligne puis de la comparer à chaque lecture d'un octet de la ligne. Mais cela signifie : stocker cette adresse au début de la ligne, puis la récupérer à chaque lecture et la comparer avec l'adresse courante. Avoir un zéro en marqueur de fin, c'est juste vérifier que l'octet qu'on vient de lire (et qu'on doit de toute façon lire) est égal à zéro. C'est nettement plus rapide.

Et je pense que c'est le choix de la rapidité qui a été fait.

[David.G]

@Mokona: Excellent. Merci beaucoup pour tes explications très détaillées. Le chemin s'éclaire...