Accueil Ti-Gen Foire Aux Questions Chat sur le chan #tigcc sur IRC
Liste des membres Rechercher Aide
Bienvenue Invité !   Se connecter             Mes sujets   
Administrer
0 membre(s) et 1 visiteur(s) actif(s) durant les 5 dernières minutes Utilisateurs actifs : Aucun membre + 1 visiteur
Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.
  :: Index » Forum Ti68K » Projets » GFA Basic oncalc (128 réponse(s))
./POST DE DEPART (post n°0)   Marquer comme non lu.
geogeo Ecrit le: Dimanche 11 juillet 2004 à 22:42 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


A cause d'Ephyx :D Je me suis lancé dans la création d'un interpréteur basic oncalc sur TI68K, le but de ce projet et d'executer une source au format GFA Basic.
Le GFA Basic est un lanage qui se présente comme le TI-Basic mais avec d'énormes possibilités et une vitesse d'execution très importante, à tel point que certain logiciel professionnels ont été réalisés avec ce langage. A savoir que sur Atari ST à 8 MHz une boucle FOR vide de 10000 cycles s'execute environ en 0.4 s, contrairement à nos TIs où il faut 55 sec :D

Ce langage est d'une puissance étonnante à tel point qu'il est possible d'améliorer les performances en spécifiant le type des variables.
Il offre aussi des fonctions proches de la machine, comme l'écriture ou la lecture directe en mémoire, la possibilité d'utiliser des pointeurs, la possibilité de créer des variables type données pour des sprites, tables...

Maintenant comment j'ai orienté mon travail, pour l'instant je n'ai pas étudié les cas compliqués comme les procedures, l'importation de code via d'autres fichiers..., je me base sur un listing unique comme le TI-Basic.

Je pense que pour executer un programme GFA au format texte il faut 3 étapes:
- Analyse syntaxique de base:
Ligne à ligne j'étudie le texte, je repère les variables, nombre, signe et je stocke ça dans une pile d'instruction, bien entendu je stocke seulement si la syntaxe de base est correcte.
- Analyse de la pile d'instructions:
La pile d'instructions est remise à jour toute les lignes, le traitement du texte se fait donc ligne à ligne, le but de cette analyse est de remettre dans un ordre compréhensible pour la machine les instructions... et à partir de là générer un code type tokenisé.
- Execution du code:
Alors là j'hésite car la meilleure des solutions serait de traiter les tokens et de réaliser un code machine, pour l'instant je penses que le mieux est de lire les tokens et de les executer 'un par un'. Normalement si je me débrouille bien il sera tout de même possible de traiter les tokens pour générer un code machine.

Quand à savoir où seront stocké les variables et sous quelle forme, je ne sais pas encore mais il faut savoir que si une variable n'a pas été définie par l'utilisateur elle peut avoir un typage dynamique.

L'objectif de ce langage est d'être puissant, accessible à tout le monde, de prendre peu de mémoire.

Pour l'instant j'ai commencé l'analyseur syntaxique de base, il est capable d'analyser une source en Basic qui ne comprent pas les caractères < > ( ), les régles de priorités des opérateurs... seront définies dans l'analyseur de la pile d'instructions.

Je pense que je m'oriente mal dans certaines choses? Et surtout je voudrais savoir un peu comment focntionne le TI-Basic, plus particulièrement dans la 'mise en ordre' des instructions comme par exemple: (i+8)*(52+j) ou encore i*(8+2).

-Edité le Dimanche 11 juillet 2004 à 22:44 par geogeo-
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°1   Marquer comme non lu.
Sasume Ecrit le: Dimanche 11 juillet 2004 à 23:33 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

Bonne chance, et bravo si tu y arrives !
    
./Post n°2   Marquer comme non lu.
Sasume Ecrit le: Lundi 12 juillet 2004 à 00:50 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

Tu as des connaissances quand même en compilation avant de te lancer dans ce projet (enfin, d'après ce que tu as dit, tu as déà commencé...) ?
    
./Post n°3   Marquer comme non lu.
geogeo Ecrit le: Lundi 12 juillet 2004 à 01:28 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Notion en compilation, malheuresement non, c'est pour ça que j'ai dit que pour l'instant je ferais sous forme de tokens à executer mais il sera toujours possible plus tard de générer un code machine.

Et oui j'ai déjà commencé l'analyseur syntaxique de base qui est capable de repérer les plus grosses erreurs de syntaxe et de compléter la pile d'expressions comme il faut.
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°4   Marquer comme non lu.
mathiniste Ecrit le: Lundi 12 juillet 2004 à 07:42 Déconnecté(e)    Voir le profil de mathiniste Envoyer un email à mathiniste Envoyer un message privé à mathiniste  

Bonne chance!
la mort n'a aucun rapport avec nous.Quand nous sommes vivants, la mort n'est pas là et quand elle est là, nous ne sommes plus...
    
./Post n°5   Marquer comme non lu.
Sasume Ecrit le: Lundi 12 juillet 2004 à 09:45 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

Des notions de compilations, ça ne veut pas dire être capable de générer du code.
La différence entre un interpréteur et un compilateur est mince.
Je parlais de tout ce qui est analyse syntaxique du programme. Je pense que c'est plutôt compliqué, et qu'il faut se documenter pour savoir quels algorithmes utiliser pour éviter de passer trop de temps (l'analyse lexicale elle-même peut représenter 30% du temps si tu ne fais pas attention à ce que tu fais (trop de passes par exemple)).
    
./Post n°6   Marquer comme non lu.
Benjy Ecrit le: Lundi 12 juillet 2004 à 11:02 Déconnecté(e)    Voir le profil de Benjy Envoyer un email à Benjy Visiter le site WEB de Benjy Envoyer un message privé à Benjy  


oui tres tres bonne chance mais pojet ambitieux :):)
Le langage C y'a pas mieux!!!
    
./Post n°7   Marquer comme non lu.
geogeo Ecrit le: Lundi 12 juillet 2004 à 12:14 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Sasume :
Des notions de compilations, ça ne veut pas dire être capable de générer du code.
La différence entre un interpréteur et un compilateur est mince.
Je parlais de tout ce qui est analyse syntaxique du programme. Je pense que c'est plutôt compliqué, et qu'il faut se documenter pour savoir quels algorithmes utiliser pour éviter de passer trop de temps (l'analyse lexicale elle-même peut représenter 30% du temps si tu ne fais pas attention à ce que tu fais (trop de passes par exemple)).


L'analyse syntaxique du programme se fait une bonne fois pour toute mais ce n'est pas elle qui va jouer sur les performances du langage. Ensuite il n'y a qu'une passe sur le ficher, le traitement se fait ligne à ligne, le but étant qu'à chaque ligne je dois construire un ensemble de tokens.
Poour l'instant j'ai construit les régles de base du langage et le traitement est très rapide mais maintenant reste à déterminer la gestion des parenthèses.
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°8   Marquer comme non lu.
Sasume Ecrit le: Lundi 12 juillet 2004 à 13:12 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

geogeo :
L'analyse syntaxique du programme se fait une bonne fois pour toute mais ce n'est pas elle qui va jouer sur les performances du langage.

Ah bon ? Pourquoi ?

Ensuite il n'y a qu'une passe sur le ficher, le traitement se fait ligne à ligne, le but étant qu'à chaque ligne je dois construire un ensemble de tokens.

Une seule passe ? Comment tu fais pour les goto ? Enfin, c'est possible de le traiter en temps d'exécution, mais ça ralentit bien...

Poour l'instant j'ai construit les régles de base du langage et le traitement est très rapide mais maintenant reste à déterminer la gestion des parenthèses.

Et des priorités des opérateurs, et laa gestion des erreurs de syntaxe, etc...
    
./Post n°9   Marquer comme non lu.
geogeo Ecrit le: Lundi 12 juillet 2004 à 14:32 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Je n'execute pas le code ligne à ligne, je transforme le code en tokens ligne à ligne, c'est pas la même chose. Ensuite pour déterminer les gotos, blocs de boucles... Par exemple FOR:

FOR I%=0 TO 500
'instructions
NEXT I

Il y a 3 étapes, la première analyser la syntaxe et compléter la pile d'expressions, la pile d'expressions doit contenir des tokens et doit être de cette forme:

FOR=Variable ou focntion
I%=Variable type entier
= = Affectation
0 = Valeur entière
TO=Variable ou focntion
500=Valeur entière

Je détermine FOR, c'est une instruction de base, ça structure est toujours identique, le but est d'obtenir les tokens suivants:

0->I
I=0:Condition:FAUX aller à adresse:VRAIE aller à adresse si l'adresse=NULL tout simplement on continu.

Voilà la travail de la première ligne

La dernière ligne:
On recherche dans la table temporaire d'info si il y a eu une boucle for pour la variable I, si c'est ce n'est pas le cas on génére une erreur si c'est le cas:

On réalise les tokens suivant:
I+1->I
Aller à adresse x.
Bien sûr le cas de la boucle FOR, un peu complexe, il faudra enregistrer l'adresse actuelle dans le token près du traitement de FOR .. TO

A savoir que j'en suis pas encore là et donc j'ai pas fait dans les détails.
A savoir une fois le texte tokenisé, il reste plus qu'à executer 'le code'

Pour l'instant j'ai fait la base, c'est à dire que mon programme estpour l'instant capable d'analyser une source en GFA Basic et de déterminer les erreurs de syntaxe soit 80% des erreurs de syntaxe et est capable de remplir la pile d'expressions.
La syntaxe suivante est incorrect mais l'analyseur syntaxique est incapable de trouver les erreurs:
i=i=2
ou encore:
i=i
ou encore 2+"toto"

Seul un traitement de la pile d'expressions permettera de trouver toutes les erreurs de syntaxes et de déterminer l'ordre de priorité des opérateurs.

Donc en gros le logiciel focntionnera comme ça:

Analyseur de base, ligne à ligne, le but étant de rempliur la pile d'expressions et de déterminer les grosses erreurs de syntaxe.

Analyseur de la pile d'expressions, but du jjeu, mettre dans un ordre correct les instructions et les variables en respectant la priorité des opérateurs... déterminer les erreurs de logiques et de syntaxe et construire une suite de tokens.

Execution des tokens, token après token, lorsque le fichier a été entièrement lu et transformé, plus la lecture des tokens est rapide, plus la vitesse du langage est importante.
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°10   Marquer comme non lu.
Sasume Ecrit le: Lundi 12 juillet 2004 à 14:45 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

Comment tu fais pour déterminer à quelle adresse on doit aller lors d'un saut ? (c'était ça ma question à la base je ne voulais pas que tu décrives précisément ton principe de tokenisation....)
    
./Post n°11   Marquer comme non lu.
geogeo Ecrit le: Lundi 12 juillet 2004 à 16:16 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Alors y a 2 solutions, soit mes sauts sont forme d'adresse donc ça prend 4 octets en plus ou soit sous forme de position dans le code tokenisé donc 2 octets.

Mais le principe est le même. J'ai une recherche de texte, si je rencontre un goto je stocke dans une table la postion ou l'adresse du token goto et l'info comme quoi le token adresse doit être modifié, pour l'instant l'adresse de saut est inconnue, une fois que je rencontre un label je stocke l'adresse du token ou sa position dans la table du ou des gotos y faisant référence. Il reste ensuite tout à la fin de l'analyse d'attribuer tout les adresses ou positions.

J'espère que c'est quand même assez clair mon explication? Une table de sauts dont les adresses sont inconnues, complèter la table lors de la rencontre d'un label et modifier l'adresse près du token de saut faire ça à la fin de l'analyse. Ce principe est identique pour les boucles for...
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°12   Marquer comme non lu.
Sasume Ecrit le: Lundi 12 juillet 2004 à 16:26 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

Je te conseille la deuxième solution (2 octets) je ne vois pas vraiment quels avantages la première solution procure.
    
./Post n°13   Marquer comme non lu.
geogeo Ecrit le: Lundi 12 juillet 2004 à 16:52 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Oui tu as raison. L'analyseur syntaxique de base, soit la grammaire du langage est bientôt terminé. Il faut ensuite que j'analyse la pile d'expressions histoire de mettre les éléments dans un ordre correct et suivant les priorités des opérateurs, j'ai commencé à faire des recherches sur le net sur l'architecture de l'arbre de récurence mais je ne trouve aucun site qui explique précisément le fonctionnement de cet arbre... Quelqu'un aurait un lien?
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°14   Marquer comme non lu.
Sasume Ecrit le: Lundi 12 juillet 2004 à 17:06 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

Un arbre de récurence ?
Il y a un topic qui a été fait sur le parsing il n'y a pas longtemps sur yN, dans la partie algo nitro y a posté des tonnes de liens utiles comme à son habitude. Peut-être que tu trouveras des infos.
    
./Post n°15   Marquer comme non lu.
geogeo Ecrit le: Lundi 12 juillet 2004 à 18:22 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


ok merci.
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°16   Marquer comme non lu.
geogeo Ecrit le: Mardi 13 juillet 2004 à 02:19 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Bon je viens de finir une grosse partie de l'analyseur syntaxique de base, il est donc capable de trouver plus de 80% des erreurs de syntaxe, il traite un fichier de 10 Ko en 1sec, il me reste certaines propriétés grammaticales du langage à définir pour ensuite passer au traitement de la pile d'expressions. Pour l'instant je pense traiter la pile d'expressions sans arbre, histoire d'avoir une méthode plus adapté aux TIs.

Je viens aussi de me documenter au sujet du GFA Basic et le traitement que j'effectue ligne à ligne peut être tout simplement fait au cour de l'écriture du programme par l'utilisateur. ;)

Ensuite les typage ne seront pas dynamique pour la simple et bonne raison que c'est trop lent et complexe à gérer pour pas grand chose.
Pour l'instant il y a 3 typages maximum:
I = Variable simple type flottant de 6 octets.
I% = Variable entière de 32 bits signée.
I! = Variable booléennes 0 ou -1
I$ = Variable type chaîne de caractères

Ensuite une variable doit toujours commencer par une lettre ou _ est a pour l'instant une longueur limite de 16 octets mais je peux éliminer cette contrainte.

Pour différencier toutes les variables, la longueur du nom est prise en compte, aucune différence n'est faite entre majuscules et minuscules.

Il sera possible mais bien plus tard d'obtenir un pointeur et d'accèder à la zone de stockage des variables du GFA.

Pour stocker une chaîne de caractère ou tableau je pense utiliser un descripteur stocké sur 6 octets, 4 octets=adresse et les 2 derniers dépendent de la chaîne ou du tableau, exemple pour une chaîne il donne la taille. Si la chaîne est impaire on trouvera l'octet NULL. Je crois qu'on nomme ça backtrailer.

Pour stocker un tableau, comme une chaîne, les 4 octets pour l'adresse de début du tableau et les 2 derniers octets le nombre de dimensions du tableau. Au début du tableau se trouvant contenu dans chaque fois quatre octets les nombres d'éléments dans chaque dimension. On commence par la dernier dimension. Ensuite on trouve le contenu des différents éléments du tableau qui dépend du type du tableau (entiers, chaînes, flottants, booélens).

Voici un bout de source d'un programme en GFA. Les fonctions GEMDOS s font référence au système d'exploitation et les fonctions XBIOS au BIOS de l'atari ST.

ON ERROR GOSUB fin
ON BREAK GOSUB fin

RESERVE 50000
super%=GEMDOS(32,L:0)
resol&=XBIOS(88,W:-1)
sauve_ecr%=XBIOS(2)
buffer%=MALLOC(77824)
image%=buffer%+1024
moniteur%=XBIOS(89)
key|=BYTE{&H484}
IF moniteur%=2
  ~XBIOS(5,L:image%,L:image%,W:3,W:&X100110011)
ELSE
  ~XBIOS(5,L:image%,L:image%,W:3,W:&X11) 
ENDIF
OUT 4,18
CLS

{&HFFFF9800}=0
{&HFFFF9800+255*4}=&HFFFF00FF

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°17   Marquer comme non lu.
geogeo Ecrit le: Mardi 13 juillet 2004 à 13:58 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


L'analyseur syntaxique de base est terminé, il faut maintenant que je m'attaque à la gestion de la pile d'expressions.
Après une grande reflexion j'ai trouvé un format de gestion des calculs qui peut fonctionner, je voudrais avoir votre avis là dessus. Pour l'instant mon but est de remettre la pile d'expressions dans un bon ordre et de trouver une gestion rapide avec les tokens.

Les 3 étapes pour gérer un calcul simple:
1) -Le texte, analyse des expressions.
2) -Mise en ordre des expressions.
3) -Execution du calcul.

L'execution du calcul se base sur 2 variables nommées tampon0 et tampon1 et sur une pile dite TSR (Temporary Stack of Results), la pile ne doit jamais être vide.

1) I=a+b+c+d
2) ab+cd++=I

3)
a->tampon0
b->tampon1
+ (empiler resultat dans la pile, vider tampon)

c->tampon0
d->tampon1
+ (empiler resultat dans la pile TSR, vider tampon)
+ (si les 2 tampons vides, calcul de TSRn-1+TSRn , résultat dans TSRn-1 et dépiler TSR.
= Préparation d'affectation
I Stocke TSRn dans I

1) I=a+b+c
2) ab+c+=I

3)
a->tampon0
b->tampon1
+ (empiler résultat dans la pile TSR, vider tampon)
c->tampon0
+ (tampon1 vide, calcul de tampon1 et TSRn, résultat dans TSRn, vider tampon)
= Prépare affectation
I Stocke TSRn dans I


1) string$(int#((a+b)(i=52.5*t)))
2) 52.2t*=Iab+*int#string$

3)
52.2->tampon0
t->tampon1
* Empiler résultat sur TSR
= Prépare affectation
I Stocke TSRn dans I
a->tampon0
b->tampon1
+ Empiler résultat
* Tampons vides donc calcul avec TSRn-1 et TSR, résulat dans TSRn-1 et dépiler TSR
int# calculer, résultat dans TSRn
string$ calculer, résultat dans TSRn

Il faut penser que int# et string$ passe par une pile d'arguments repérable grâce aux virgule et donc le premier argument de base=TSRn.

Dites moi ce que vous en pensez et quels sont les cas que cette méthode ne pourra pas gérer, j'ai pas encore fait dans les détails, pour l'instant ceci est une première ébauche d'idées. Si vous avez plus rapide avec moins de conditions... je suis partant.
-Edité le Mardi 13 juillet 2004 à 14:14 par geogeo-
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°18   Marquer comme non lu.
geogeo Ecrit le: Mardi 13 juillet 2004 à 18:29 Déconnecté(e)    Voir le profil de geogeo Envoyer un email à geogeo Visiter le site WEB de geogeo Envoyer un message privé à geogeo  


Enfin de compte les tampons sont inutiles :D
Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic
    
./Post n°19   Marquer comme non lu.
Sasume Ecrit le: Mardi 13 juillet 2004 à 19:19 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

Ah, ça n'accélère rien ?
    
  :: Index » Forum Ti68K » Projets » GFA Basic oncalc (128 réponse(s))
Pages : 1/7     « [1] 2 3 4 5 6 7 » »|

.Répondre à ce sujet
Les boutons de code
[B]old[I]talic[U]nderline[S]trikethrough[L]ine Flip Hori[Z]ontallyFlip [V]erticallySha[D]ow[G]low[S]poilerCode [G][C]ite
Bullet [L]istList Item [K] Link [H][E]mail[P]icture SmileysHelp
Couleurs :
Saisissez votre message
Activer les smileys
     

Forum de Ti-Gen v3.0 Copyright ©2004 by Geoffrey ANNEHEIM
Webmaster: Kevin KOFLER, Content Admins: list, Server Admins: Tyler CASSIDY and Kevin KOFLER, DNS Admin: squalyl
Page générée en 43.49ms avec 18 requetes