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

Onur :
Non pas forcement avec les routines de TIOS.. Tout ce qui est local est géré par la pile.

Ha, intéressant comme méthode.

Soit le programme :

Prgm
Local i,j,l,s
seq({},i,1,5)->l
While not eof()
read()->s
For i,1,5
instring(s,"-")->j
augment(l[i],{mid(s,1,j)})->l[i]
mid(s,j+1)->s
EndFor
EndWhile
EndPrgm

Tu m'expliques comment tu gères "tout ce qui est local" (ici, les divers l[i]) par la pile ?

Encore une fois, je crois que tu n'as vraiment pas saisi la subtilité, et que pour tout un tas d'applications, soit ça va être aussi lent que le TI-Basic (si tu utilises les routines du TIOS) tout en étant largement plus gros, soit ça va demander une réécriture complète du programme (le programme que j'ai écrit plus haut ne passera pas tel quel avec une allocation via la pile, ou alors je suis intéressé par ta méthode --- si elle ne consiste pas à faire bêtement des listes chaînées, bien sûr : mais on peut faire des contre-exemples un peu plus évolués, dans ce cas-là; et en plus je doute que ton compilo fasse une analyse du code pour voir si c'est plus intéressant d'utiliser des listes chaînées ou des tableaux "normaux"...)

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.

Ha. Donc interdire d'accéder à certaines fonctions d'allocation, c'est améliorer les choses ? Si le Basic reste une alternative intéressante au C, c'est précisément parce que certaines constructions (du genre de celle que j'ai décrite plus haut) sont très pénibles en C à cause de la gestion de la mémoire. Si tu t'amuses à rajouter des limites hard-codées, bien sûr ce sera qd même possible de faire des petits programmes pour montrer que ton langage "tourne", mais l'intérêt est quasiment nul...

Désolé de paraître un peu aggressif, mais j'ai l'impression que vous avez des illusions sur ce qu'apportent vos deux convertisseurs "Basic"->C (toi et Quesoft) : il manque vraiment *LA* chose qui fait que le Basic est plus pratique que le C, et donc ces langages n'ont aucune commune mesure avec le Basic A la limite, on aurait aussi vite fait de porter un compilo C++ sur TI, sachant que de toute façon les exécutables C++ ne seront probablement pas plus gros que les exes "Basic"...

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.

Et ce ne sera pas pareil pour les tableaux ?

Pollux , tu es mechant avec moi
Je ne cherche pas a imiter TI-Basic (comme je l'ai deja precise) et il ne s'agit pas d'un convertisseur Basic -> C
Si tu ne le trouves pas interessant, tu n'a qu'a ne pas l'utiliser.
C'est quoi le compilateur de QueSoft??

En fait QueSoft convertis le code TI-basic en code C. Aprés, il faut compiler le code C avec TI-GCC.

ah, ouais c'est bien ca! .. et ca marche bien???
en tout cas mon compilateur convertit du ETP-Basic en assembleur et il y a un assembleur qui le convertit en code machine.

Pollux t'es méchant

et le code C généré est bon ? (avis aux testeurs)

nEUrOO
: et le code C généré est bon ? (avis aux testeurs)

Ce n'est pas du C :

Onur
: en tout cas mon compilateur convertit du ETP-Basic en assembleur et il y a un assembleur qui le convertit en code machine.

mac -> En fait QueSoft convertis le code TI-basic en code C. Aprés, il faut compiler le code C avec TI-GCC.
onur -> ah, ouais c'est bien ca!

QueSoft c'est l'autre...

arf, oki

ouai c'est pas mal mai je comprend pas le langage utilise

Peio :
Pollux t'es méchant

En fait, il est pas mechant.. c'est juste qu'il n'a pas compris que mon programme n'avait rien a voir avec celui de QueSoft.

Pour la troisieme fois, specialement pour Pollux , ETP-Basic compiler ne convertit pas en C !!!! de plus, il est completement autonome, y a pas besoin de passer par quoi que ca soit.

En fait, j'ai appele le langage ETP-Basic parce que c'est plus proche de basic que d'autre chose. J'aurais du l'appeler "choucroute" , personne ne m'aurait dit, "vaut mieux que ca soit interprete".

cerede2000 :
ouai c'est pas mal mai je comprend pas le langage utilise

TIens, tout est explique http://www.etpstudio.com/help%20Basic/main.htm

Au fait, maintenant je comprends pourquoi je comprenais rien a ce que dit Pollux, parce qu'il croyait encore que ETP-Basic utilise gcc. Du coup, je fais une petite correction, je voulais dire que j'utilise la pile pour les declarations locales ( et il n'y a pas de mal a ca

Je pense surtout que ça vient du fait qu'en basic, la gestion des variable doit être dynamique (c a dire qu'une variable a peut avoir pour valeur 25 et la ligne d'aprés {"Hello","World"}. Mais je pense que l'intéret du basic c aussi (surtout ?) l'indirection (#)^^

hum moi je prefere le C avec tigcc

Tiens, j'avais oublié de répondre à ce topic ^^

Bon pour le fait qu'il convertisse en ASM plutôt qu'en C, OK mais ça ne change rien au fond du problème : comment est-ce que tu vas gérer le programme que je t'ai donné dans ./31 ? (ou son équivalent en ETP-Basic, parce que j'imagine que le langage permettra de faire ce genre de choses ?) Je serais très curieux de voir à quoi ressemble la manière dont tu alloues sur la pile dans ton code ASM...

Et sinon je ne vois pas vraiment ce que ça t'apporte de ne pas gérer les chaînes de taille variable alors que tu gères les tableaux de taille variable et qu'il n'y a rien de fondamentalement différent ?

Pollux :
comment est-ce que tu vas gérer le programme que je t'ai donné dans ./31 ? (ou son équivalent en ETP-Basic, parce que j'imagine que le langage permettra de faire ce genre de choses ?) Je serais très curieux de voir à quoi ressemble la manière dont tu alloues sur la pile dans ton code ASM...

J'ai pas regarde precisement ton prog. Mais je suppose que tu veux savoir comment j'alloue dynamiquement de la place memoire?? ben pour l'instant tu peux pas. Mais dans le futur tu pourra faire
Local myInt as Integer
Local (ou Public si tu veux) myList as New Collection
puis
myList.add myInt

par contre la metamorphose du style:

MacIntoc
: (c a dire qu'une variable a peut avoir pour valeur 25 et la ligne d'aprés {"Hello","World"}

ne sera sans doute pas possible, en effet ca, ca necessiterait une virtualMachine interpreteur et je veux pas faire ca. Je veux que quand on met le programme realise, il marche tout seul tres bien (eventuellement un launcher pour les gros programmes).. Faire le plus simple possible pour les utilisateurs (c'est pourquoi ca sort systematiquement du noStub)

cerede2000
:hum moi je prefere le C avec tigcc

C c'est plus pour les pros (comme nous quoi ) mais il s'agit de trouver un bon compromis entre facilite durant le design et performance at the runtime.
Tu peux aussi telecharger un premier petit jeu fait avec ETP (preuve que ca marche) et regarder ca source: http://www.etpstudio.com/MiniTag.zip

Onur
:

Pollux :
comment est-ce que tu vas gérer le programme que je t'ai donné dans ./31 ? (ou son équivalent en ETP-Basic, parce que j'imagine que le langage permettra de faire ce genre de choses ?) Je serais très curieux de voir à quoi ressemble la manière dont tu alloues sur la pile dans ton code ASM...

J'ai pas regarde precisement ton prog. Mais je suppose que tu veux savoir comment j'alloue dynamiquement de la place memoire?? ben pour l'instant tu peux pas. Mais dans le futur tu pourra faire
Local myInt as Integer
Local (ou Public si tu veux) myList as New Collection
puismyList.add myInt

Ce que je veux dire, c'est que même si l'en-tête de myList sera p-ê alloué sur la pile (parce qu'on connait sa taille à l'avance), tu ne pourras pas allouer le *contenu* sur la pile et tu seras obligé de passer par les routines de heap du TIOS si tu n'en reprogrammes pas un toi-même...

par contre la metamorphose du style:

MacIntoc
: (c a dire qu'une variable a peut avoir pour valeur 25 et la ligne d'aprés {"Hello","World"}

ne sera sans doute pas possible, en effet ca, ca necessiterait une virtualMachine interpreteur et je veux pas faire ca.

Oui, tu fais un typage statique comme en VB... (mais sans type Variant)

par contre,, ce serait bien si tu pouvait gérer la reconnaissance de type automatiquement au lieu de définir à chaques fois chaques variables.

MacIntoc
: par contre,, ce serait bien si tu pouvait gérer la reconnaissance de type automatiquement au lieu de définir à chaques fois chaques variables.

Caml ?

C'est très pratique en effet.

nan c'est chiant

Pourquoi?

Parce que...

C'est un peu court...

le typage auto pour moi c'est plus une contrainte qu'autre chose

C clair que c très contraignant (pas de conversions auto...) pour un gain mineur

et qd le compilateur se chie dessus pour retrouver le type c'est source de perte de tps

sans compter que la source est bcp moins claire

oué, les erreurs de typage sont particulièrement mal reportées par caml...

les discussions pour ou contre le Caml vont dans le forum PC svp

Il y a une declaration implicite de variable
lorsque vous dites a=b*c et que b et c sont declares comme Integer, ca vous met undeclared a was implicitly declared as Integer
si vous mettez
a=798 c'est pareil
si vous mettez
a=34561 ca vous le declare comme Long
si vous mettez
a="bonjour" ca vous met comme String

ca marque bien un Warning donc source d'erreur possible, il faut faire explicitement la declaration pour le preciser soit meme.
Ouais, ca peut etre chiant.. mais bon ceux qui veulent peuvent toujours declarer. Moi je prefere declarer.
Hier j'ai corrige un petit bug, mais c'est pas fini (je dis tjrs ca non?)

Pollux :
Ce que je veux dire, c'est que même si l'en-tête de myList sera p-ê alloué sur la pile (parce qu'on connait sa taille à l'avance), tu ne pourras pas allouer le *contenu* sur la pile et tu seras obligé de passer par les routines de heap du TIOS si tu n'en reprogrammes pas un toi-même...

Non le contenu sera dans un machin trouve avec heap du TIOS, les pointeurs eventuelles dans la pile.