[mOved] Venez voir ca! un compilateur basic pour les ti - Page 1

J'ai fait un mini editeur qui permet d'utiliser un plus grand programme: un compilateur basic pour les ti89/92+/v200. vous pouvez le telecharger a http://www.etpstudio.com ou sur ticalc.org.

Bon c'est pas encore parfait, la librairie standart n'est pas termine mais je l'avance tout doucement, ce qui est difficile en cette periode d'examen. Les bugs connus sont: division d'entiers long (ca marche pas mais ca va marcher), les variables publiques (on ne peut utiliser que les variables locales), et les boucles for ne marchent pas toujours. Sinon tout le reste a l'air de fonctionner comme il faut: declaration de fonction et procedure, declaration et utilisation de variables locales, evaluation dynamique d'une expression d'entier ou de chaine de caractere avec (une surcharge s'il vous plait )
Par exemple si myVar vaut 13, il suffit d'ecrire Locate 1,1,"Cette variable vaut:" & myVar,4
et ca vous affichera: Cette variable vaut 13

Je pense que ca va etre pratique pour ceux qui ont l'habitude d'ecrire en Basic.

La lecture des touches est tout a fait possible, ainsi que l'affichage.. en attendant de completer la librairie..

Je compte faire carrement un environnement de developpement avec des Sprite editor et la gestion automatique des graphismes mais c'est pas encore fini non plus.

Quand ça compile, ça sort du Basic ou de l'ASM ?

A tiens, encors un ??

-

C'est niquel comme truc

Pas d'indirection, je suppose, ni d'expr() ??

Ca me rappelle malheureusement PowerBasic...

La particularité du type String est qu'il parait comme étant dynamique lorsque l'utilisateur programme en ETP-Basic. Les chaines de caractère peuvent etre de taille différentes. Vous pouvez déclarer une variable de type String, et lui attribuer une valeur de n'importe quelle taille. En fait, le langage a été conçu de manière à trouver un juste milieu entre facilité de programmation et mémoire utilisée lors de l'éxecution. Et les String sont des tableaux de caractère limitées à 50 caractères, elles sont donc bien statiques. Lors de l'éxecution, aucune vérification de dépassement n'est effectué, aucune exception n'est levée.

Dans cette version, vous ne pouvez pas définir un nouveau type pour le réutiliser, ni de tableau.

(et j'imagine que qd il y aura des tableaux, la taille sera elle aussi statique...)

Sérieusement, vous croyez qu'un langage avec une gestion de la mémoire aussi primitive permet d'être aussi flexible que le TI-Basic ?

ouai en meme temps les string, en basic on s'ammuse pas a faire des grosses oppérations dessus.

Oh si, va voir CHEMISLV... Une équation-bilan complexe n'entrerait même pas dans 50 octets!

Et pour du BASIC autre que TI: Tokens89: j'abuse du type String pour tout et n'importe quoi: je m'en sers entre autres de pile, de buffer de données binaires, de représentation de nombres (de longueur arbitraire), et aussi de buffer de texte comme prévu.

une équation bilan n'est pas vraiment une grande chaîne de caractère (à moins que 100o ça soit une grande chaîne pour toi ^^). Enfin, si tu fais de grosses opérations dessus, c'est peut-être pour ça qu'il est si lent ^^


quand j'étais en sup je m'étais amuser à recoder des fonctions de calcul élémentaire sur les grands entiers (qqes dizaines milliers de chiffres) avec des chaînes de caractère. donc on peut s'amuser à faire de grosses opérations dessus

100 octets, c'est déjà le double du maximum de ETP!

Pour CHEMISLV, il y a essentiellement une seule fonction qui travaille sur des chaînes de caractères: chem, qui convertit un truc comme C6H12O6 en une expression mathématique: 6*αcα+12*αhα+6*αoα. Ensuite, je passe le tout au noyau de calcul formel de AMS (fonction solve - obligé d'utiliser string et expr ici, ainsi qu'un gros hack pour avoir solve en toutes les langues) qui me rend des solutions en termes d'un @n, je détermine le dénominateur commun des solutions, je remplace le @n (dont je détermine d'abord le numéro en cherchant @ dans la chaîne) par ce dénominateur, et j'ai des solutions entières (dans le cas où j'ai plusieurs @n, c'est un peu plus compliqué, mais c'est l'idée). Et ensuite, je recolle le tout pour l'affichage.

c'est peut-être le double du maximum de ETP, mais ça reste une petite chaîne.
sinon, equbil fait à peu près la même chose, mais je ne connais plus les détails.

Enfin, pour revenir au sujet, je ne pense pas que vouloir compiler du basic est une bonne idée, à la rigueur il vaudrait mieux un meilleur interpréteur. Si on cherche à le compiler, on perd automatiquement sa souplesse :'(

En fait le plus gros pb de ces deux "basics"-là, c'est pas tellement d'être compilé (ça, ça fait juste perdre de la place, mais ça rend pas le truc totalement inutilisable), mais c'est le fait qu'ils croient qu'en se reposant sur la "gestion mémoire" du compilateur C ça leur facilitera la tâche... Malheureusement il faut impérativement de l'allocation dynamique, et si on ne veut pas perdre 95% du tps à allouer de la mémoire, il faut reprogrammer un tas...

ouai, mais pour les jeux, les chaines de caracteres restent tres rare (du moins en non static)

et ça rend la gestion des strings bien plus pénible...

ouai en meme temps un niveau géré en string faut pas s'attendre a une vitesse extra ordinaire

c'est pas SMA qui a des niveaux stockés dans des strings ?

C'est pas des strings. C'est un abus de format.

juste que sur 92 pas +, y'avait pas de types persos, fallait bien mettre les données dans des strings (ou des expr, ou... enfin abuser un format quoi)

Et SMA marche sur 92 normale.

hum... II

si, si. Je te jure. Mais pas avec les niveaux fournis. Faut se faire ses propres (tout petits) niveaux

Bon il est temps de répondre à quelques questions et remarques...

MacIntoc
: A tiens, encors un ??

ben.. je savais pas qu'il y avait un compilateur Basic pour TI?? c koi??

geogeo :
C'est niquel comme truc

Merci cher collegue de chez Orage

MacIntoc
: Pas d'indirection, je suppose, ni d'expr() ??

Non, je tiens a préciser qu'il ne s'agit pas d'une copie de TI-Basic mais tout un autre langage. Il se trouve que les deux sont dérivés de Basic, mais je n'essaie pas de copier TI-Basic. C'est vrai qu'il peut intéressant de faire un re-compilateur qui traduit de TI-Basic à ETP-Basic, s'il y a des courageux...

Pollux :
(et j'imagine que qd il y aura des tableaux, la taille sera elle aussi statique...)

Sérieusement, vous croyez qu'un langage avec une gestion de la mémoire aussi primitive permet d'être aussi flexible que le TI-Basic ?

Le compilateur n'est pas terminé. Apres les bugs que j'ai cité à mon premier message, la première chose à faire est de s'attaquer aux tableaux et ensuite les variables de type booléenne et à virgule flottante avec des fonctions mathématiques qui en découlent qui seront ajoutés dans la librairie standart.
Les tableaux seront crées de taille quelconque, d'ailleurs la taille pourra être précisé lors de l'éxécution (allocation dynamique). Le choix de l'implementation d'une taille constante à une déclaration du style Local myStr as String vient de la raison suivante..

J'ai crée ce compilateur pour pouvoir facilement créer des jeux même si on n'est pas un boss en prog. Bien qu'on peut discuter de l'utilisation des chaines de caractères, une taille statique de 50 caractère me semblait un bon compromis entre la facilité de programmation et l'utilisation de la mémoire. Je pense rajouter la possibilité de préciser la taille des chaines de caractère et dans le cas d'un manque de paramètre, ca fonctionnera comme maintenant càd à 50 char.
Puisque l'utilisateur va pouvoir créer des tableaux, il pourra sauvegarder des données la dedans sans avoir à utiliser une variable de type String.

JackosKing VNR
: ouai en meme temps les string, en basic on s'ammuse pas a faire des grosses oppérations dessus.

Ouais j'ai quand meme voulu mettre des operations de String et des fonctions qui les manipulent, je sais pas ca peut tjrs servir (pour les Hi-score par exemple..)

Pollux
: En fait le plus gros pb de ces deux "basics"-là, c'est pas tellement d'être compilé (ça, ça fait juste perdre de la place, mais ça rend pas le truc totalement inutilisable), mais c'est le fait qu'ils croient qu'en se reposant sur la "gestion mémoire" du compilateur C ça leur facilitera la tâche... Malheureusement il faut impérativement de l'allocation dynamique, et si on ne veut pas perdre 95% du tps à allouer de la mémoire, il faut reprogrammer un tas...

Ouais, je crois que coté gestion de la mémoire (a part les String), mon compilateur reste correcte (cf test de calcul de Fibonacci en recursive)

JackosKing VNR
: ouai, mais pour les jeux, les chaines de caracteres restent tres rare (du moins en non static)

Tu as tout compris


A part ca, y'en a qui ont vraiment essayé programmer avec?? ou qui ont compilé les exemples pour les tester??

Onur
:

Pollux :
(et j'imagine que qd il y aura des tableaux, la taille sera elle aussi statique...)

Sérieusement, vous croyez qu'un langage avec une gestion de la mémoire aussi primitive permet d'être aussi flexible que le TI-Basic ?

Le compilateur n'est pas terminé. Apres les bugs que j'ai cité à mon premier message, la première chose à faire est de s'attaquer aux tableaux et ensuite les variables de type booléenne et à virgule flottante avec des fonctions mathématiques qui en découlent qui seront ajoutés dans la librairie standart. Les tableaux seront crées de taille quelconque, d'ailleurs la taille pourra être précisé lors de l'éxécution (allocation dynamique). Le choix de l'implementation d'une taille constante à une déclaration du style Local myStr as String vient de la raison suivante..

Euh, je pense que c pas trop la peine de demander, mais j'imagine que tu utilises les routines du tios pour allouer tes tableaux... Ca va faire des trucs tellement lents qu'il faudra impérativement limiter l'alloc dynamique au strict nécessaire (comme en C) Ca veut dire qu'il faudra probablement d'abord déterminer la taille à allouer, puis allouer le tableau et seulement après l'écrire... Ce qui fait que c'est aussi chiant à faire qu'en C

Accessoirement, je ne vois pas pkoi tu fais une différence fondamentale entre tableau et chaîne C'est exactement la même chose, sauf que la chaîne a juste l'avantage supplémentaire d'avoir un type de base bien connu...

Non pas forcement avec les routines de TIOS..
Tout ce qui est local est géré par la pile. Ta methode est sans doute bien et ca ne sera pas pareil qu'en C parce que justement je peux faire en sorte que ca soit transparent pour l'utilisateur. Le Basic est destiné aux gens qui ne veulent pas se prendre la tete.
Bien sur qu'il n'y aucune difference pour un programmeur C ou asm entre une chaine de caractère et un tableau (enfin les chaines statiques je parle) mais dans mon cpomilateur un truc déclaré du type String va etre automatiquement interprété en String lors d'une affectation ou passage en argument. Je voulais dire que les utilisateur peuvent sauver des infos dans des tableaux d'entier par exemple.
Encore une fois, il s'agit de trouver un compromis entre facilité et rapidité... un compromis différent de C, un compromis plutot du coté de facilité

Ximoon
: juste que sur 92 pas +, y'avait pas de types persos, fallait bien mettre les données dans des strings (ou des expr, ou... enfin abuser un format quoi)

Donc on utilise un format différent selon la calculatrice de destination. Backgammon pour Fargo utilise des STR, la version _nostub utilise des BGAM.

on y perd en compatibilité

Pour le type String, à mon avis, la bonne représentation en C est HANDLE.
Par exemple pour la concaténation:

HANDLE str1,str2;
HeapReallocThrow(str1,strlen(HeapDeref(str1))+strlen(HeapDeref(str2))+1);
strcat(HeapDeref(str1),HeapDeref(str2));

(attention, le HeapDeref ne peut pas être factorisé en des variables parce que l'adresse peut être changée par le HeapReallocThrow).

Flanker
: on y perd en compatibilité

Si tu veux vraiment utiliser une sauvegarde de TI-92 sur TI-89/92+/V200 ou vice-versa, je peux aussi implémenter ça... Mais je ne vois pas trop l'intérêt.