Power Basic - Page 1

Bonjour.

Je vais bientôt lancer une version alpha de Power Basic, un convertisseur TI-BASIC à C. Pour 'étendre' le TI-BASIC et offrir plus de possibilités aux programmeurs je vais probablement inclure la librairie libre FLIB. J'aimerais que vous me fassiez part de vos suggestions (entre autres, FLIB est-elle encore la librairie libre la plus utilisée ?) et que ceux qui sont itéressés à implémenter de nouvelles fonctionnalités m'en fassent part. Également, vous pouvez poster vos interrogations.

il me semble que certains vont te repondre que vertel est la librairie la plus utilisée

Sinon, ton programme traduira les commandes en C réellement ou utilisera les commandes C qui font appelles aux commandes du TIOS ?

y333 :
il me semble que certains vont te repondre que vertel est la librairie la plus utilisée

C'est possible, je ne peux les contredire. Est-elle libre (open source) ?

Convertir le TI-BASIC vers le C n'est peut-être pas une très bonne idée. Tu seras obligé d'utiliser les fonctions de AMS qui sont la cause de la lenteur du TI-BASIC, donc le gain de performances sera relativement faible. En intégrant flib, pkoi pas, ça serait plus intéressant si c'était bien fait, mais encore une fois, je ne pense pas que le gain de performances serait phénoménal.

vertel n'est pas OpenSource, mais si tu demandes gentiment à Vertyos, il y a des chances qu'il veuille bien te fournir les sources

Je pense que même en utilisant les ROM_CALLs, on peut accélérer les programme d'un facteur 100 s'ils sont réécrits en C.
Cependant, les possibilités du BASIC sont assez limitées, et même s'il devient plus rapide, je trouve que ça a peu d'intérêt...

GoldenCrystal
: Convertir le TI-BASIC vers le C n'est peut-être pas une très bonne idée. Tu seras obligé d'utiliser les fonctions de AMS qui sont la cause de la lenteur du TI-BASIC, donc le gain de performances sera relativement faible. En intégrant flib, pkoi pas, ça serait plus intéressant si c'était bien fait, mais encore une fois, je ne pense pas que le gain de performances serait phénoménal.

En fait, la syntaxe du TIBasic est conservée. Cependant, les 'effets' des instructions sont différents. Par exemple :
Toto(a)
Prgm
LineHorz a
Pause
EndPrgm

Affiche un ligne horizontale directement sur l'écran, et non dans l'écran graphique.

vertel n'est pas OpenSource, mais si tu demandes gentiment à Vertyos, il y a des chances qu'il veuille bien te fournir les sources

Je ne doute pas de la gentillesse de cet individu, mais comme mon projet est sous GPL, je ne peux incorporer de code propriétaire sans que la personne qui détient le copyright licencie sous GPL.

Sasume :
Je pense que même en utilisant les ROM_CALLs, on peut accélérer les programme d'un facteur 100 s'ils sont réécrits en C. Cependant, les possibilités du BASIC sont assez limitées, et même s'il devient plus rapide, je trouve que ça a peu d'intérêt...

Vous avez raison et c'est pourquoi je désire incorporer une librairie connue pour 'étendre' le TI-BASIC.

Je pense que c'est quand même beaucoup d'énergie pour pas grand chose de réellement utile...

FLib est plus lente que le ti-basic.

Sasume
: Je pense que c'est quand même beaucoup d'énergie pour pas grand chose de réellement utile...

Peut-être, mais je le fais, entre autres, parce que lorsque je faisait du basic, la vitesse était une lacune importante et que plusieurs programmeurs n'ont pas le temps, ni l'intérêt d'apprendre le C (ou le Java avec Moka) ... et c'est domage ...

Sasume>ça évitera d'une part la lenteur de la tockénisation et d'autre part la lenteur de l'interprétation.

Pour les listes et les matrices, ce serat géré comment ??

MacIntoc
: FLib est plus lente que le ti-basic.

C'est possible, car les commandes sont parsées (interprétées, je sais ) avant d'être exécutées. Mais si FLIB, ou une autre librairie est incorporée à Power Basic, les appels de fonctions seront compilés, donc rapides.

A ui, exact.
Je me demandait, si FLib peut-être adapté, est-ce que les librairies statiques en C peuvent être utilisé ??

MacIntoc :
A ui, exact. Je me demandait, si FLib peut-être adapté, est-ce que les librairies statiques en C peuvent être utilisé ??

Pour l'instant ce n'est pas implémenté (l'alpha est pas encore distribué, j'attend d'avoir incorporé la pluspart des fonction TI-BASIC disponibles), mais c'est quelque chose qui peut être fait assez facilement. Dans le fond, ça revient à ajouter un header et un fichier de code source C au projet. Pour ce faire, je dois modifier l'IDE, et permettre l'appel de fonction C sans avoir à passer par

Native

EndNative

Un appel de fonction pourrait ressembler à :
CALL drawPix(10,10)

Merci pour la suggestion.

Quesoft a raison, dans les programmes basic, c'est la transformation basic -> rom_call qui prend du temps (je sais que c'est pas exactement ça, mais c'est l'idée), c'est pas quand les rom_call ont la main que c'est lent. Pour être plus clair, la lenteur d'un "disp "coucou" ", par exemple, vient du temps que l'AMS met à "comprendre" qu'il faut faire un printf, pas à faire le printf

pareil pour les appels à flib, c'est le temps de chargement de flib qui rend les choses si lentes

Flanker :
Quesoft a raison, dans les programmes basic, c'est la transformation basic -> rom_call qui prend du temps (je sais que c'est pas exactement ça, mais c'est l'idée), c'est pas quand les rom_call ont la main que c'est lent. Pour être plus clair, la lenteur d'un "disp "coucou" ", par exemple, vient du temps que l'AMS met à "comprendre" qu'il faut faire un printf, pas à faire le printf
pareil pour les appels à flib, c'est le temps de chargement de flib qui rend les choses si lentes

Effectivement, mais en plus, Power Basic n'utilise pas cmd_Disp (si cette fonction existe dans la TIGCC lib), mais printf directement. C'est moins '100% compatible' avec TI-BASIC, mais c'est plus rapide. Le but de Power Basic est de permettre aux programmeurs TI-BASIC de faire des programmes plus puissant, sans avoir à apprendre un nouveau langage.

[ edit par Ximoon: partie du message supprimée ]

*Je ne doute pas de la gentillesse de cet individu, mais comme mon projet est sous GPL, je ne peux incorporer de code propriétaire sans que la personne qui détient le copyright licencie sous GPL. *
Bien dit. Donc Flib 3.2.

MacIntoc:
*FLib est plus lente que le ti-basic. *

Ca vient de sortir, alors...
Tu as déjà fait des tests sur le temps que mettent plusieurs centaines
de sprites à s'afficher, d'abord par RclPic/RplcPic puis par flib("sprite") ?

Quesoft > Je ne pense pas qu'il soit utile d'adapter flib.
Fait juste une traduction en C des instructions TI-Basic
(un vrai parsing), convertit tout, les listes n'ont pas à être changées,
les matrices doivent passer de [[1,2,3][4,5,6]] ou [1,2,3;4,5,6] à {{1,2,3},{4,5,6}}. Pour les instructions (genre RclPic truc) traduit par des fonctions C.

Mais de toute manière tu vas t'emmerder:
Comment vas-tu gérer les variables ?
Les variables TIOS seront utilisées ?
Et si j'ai une variable STR et que je lui affecte 10...
Est-ce que tu as quoi que ce soit pour gérer ça ?
Dans le meilleur des cas tu vas devoir créer une structure
(qui pourrait s'appeler... Variant) et traduire toutes les
additions de variables TI-Basic en C par des appels de fonctions
genre AddVariant(Var1,Var2); et là je suis gentil, y'a plein d'autres
trucs... Au niveau des graphiques notamment....

Kitsune :
[Quesoft:
*C'est possible, je ne peux les contredire. Est-elle libre (open source) ? *
Oui, si t'es un connard.

Ça sent le fanatisme religieux

Le convertisseur existe déjà. C'est juste que je n'ai pas implémenté toutes les features. Donc pour répondre à vos questions :

Kitsune :
Quesoft > Je ne pense pas qu'il soit utile d'adapter flib.
Fait juste une traduction en C des instructions TI-Basic
(un vrai parsing), convertit tout, les listes n'ont pas à être changées,
les matrices doivent passer de [[1,2,3][4,5,6]] ou [1,2,3;4,5,6] à {{1,2,3},{4,5,6}}. Pour les instructions (genre RclPic truc) traduit par des fonctions C.

C'est ce qui sera fait, bien sûr. Power Basic considère les listes au même titre que des matrices à 1 dimension.

Kitsune :
Mais de toute manière tu vas t'emmerder:
Comment vas-tu gérer les variables ?

Comme en VB, l'horrible type Variant, comme vous proposez plus bas.

Kitsune :
Les variables TIOS seront utilisées ?

Oui, mais pas directement :
IMPORT maVar

EXPORT maVar

Kitsune :
Et si j'ai une variable STR et que je lui affecte 10...
Est-ce que tu as quoi que ce soit pour gérer ça ?
Dans le meilleur des cas tu vas devoir créer une structure
(qui pourrait s'appeler... Variant) et traduire toutes les
additions de variables TI-Basic en C par des appels de fonctions
genre AddVariant(Var1,Var2); et là je suis gentil, y'a plein d'autres
trucs... Au niveau des graphiques notamment....

Comme déjà dit, Variant. À moins de déclarer explicitement une variable comme étant d'un autre type :
New vari As short
Une variable est de type variant et peut accepter n'importe quel type de données.

La seule exception est les matrices/listes. Elles doivent être déclarées, elle sont créées statiquement, mais peuvent être modifiées dynamiquement.

Ex :
'Creer une matrice de 10 x 29
NewMat toto, 10, 29

La différence avec le TI-BASIC est que
toto->tata
ne copie pas toto vers tata, mais fera plutôt que tata référencera la même matrice que toto.

Pour copier une matrice, on utilise StoMat :
StoMat tata, toto

Si tata n'est pas une matrice, le programme gèle et il faut reseter la calculatrice (ok je pourrais ajouter des vérifications).

Tout ça est déjà implémenté.

j'ai pas tout lu, mais si c'est une matrice d'expressions ?

Ben soyons réaliste:
Le mieux est que tu fasses un Basic de rien, sans forcément se ramener
au TI-Basic, car dès qu'il s'agira de manipuler les matrices TI-Basic
(Les trouver, les convertir en structures C dans le tas, implémenter les
fonctions comme det(), sum(), et j'en passe (y'aura mat->list ? )
et enfin permettre de sauvegarder à nouveau ça dans une variable TI-Basic....

Et pour intégrer toutes les possibilités de calcul formel qui font partie du TI-Basic,
ça va faire très mal. (Fonction csolve() ? )

Et pour intégrer toutes les possibilités de calcul formel qui font partie du TI-Basic,
ça va faire très mal. (Fonction csolve() ? )

bah ce sont des romcalls

Flanker
: j'ai pas tout lu, mais si c'est une matrice d'expressions ?

Ça c'est la plus grosse lacune de Power Basic vs la compatibilité avec TI-BASIC. Les expressions, style
3x +b
ne sont pas supportées.

Je ne vois pas comment implémenter leur support efficassement et j'ai l'impression que ça ne doit pas être du gâteau. Cependant, si quelqu'un est intéressé par ce sujet, je serai le premier content.

Kitsune :
Ben soyons réaliste:
Le mieux est que tu fasses un Basic de rien, sans forcément se ramener
au TI-Basic, car dès qu'il s'agira de manipuler les matrices TI-Basic
(Les trouver, les convertir en structures C dans le tas, implémenter les
fonctions comme det(), sum(), et j'en passe (y'aura mat->list ? )
et enfin permettre de sauvegarder à nouveau ça dans une variable TI-Basic....

Et pour intégrer toutes les possibilités de calcul formel qui font partie du TI-Basic,
ça va faire très mal. (Fonction csolve() ? )

Effectivement csolve n'est pas implémenté. Cependant mat->list est déjà implémenté et fonctionnel. Bien que Power Basic ne recherche pas la complète compatibilité avec TI-BASIC, j'ai tenté de garder la même syntaxe et je crois que c'est réeussi.

j'avais déjà réfléchi à un truc de ce genre, et cet obstacle m'avait arrêté (et puis j'ai arrêté le basic, ça a pas mal joué)
le plus simple (je pense) est tout simplement d'interdire les expressions de calcul formel. C'est peut-être un peu violent, mais ça a l'avantage d'être simple.
Sinon, pour le changement de type, tu peux pas déclarer plusieurs variables, genre

3 -> x
"coucou" -> x 

serait transformé en

int x_int = 3;
char[] x_char = "coucou\0";

?

Ce n'est pas une très bonne idée de faire un convertisseur Basic -> C :

* le code C va être énorme

* apparemment, tu ne vas pas faire d'approximation genre "toutes les variables sont des entiers 16 (ou 32) bits", donc ça va limiter énormément ce que tu peux gagner
(à moins de faire une analyse statique de type assez coton ) donc "While x<y:x+1->x:EndWhile" sera transformé en "while (CompareVariant(x,y)<0) x=AddVariant(x,CreateInteger(1));", ce qui fait que tu perds vraiment tout le bénéfice du C : si c'est juste pour que ton code C ressemble à des "jsr CompareVariant", "jsr AddVariant" et "jsr CreateInteger", alors ce sera probablement aussi efficace en tps et plus efficace en vitesse de passer par un tableau qui va contenir 42 (index de CompareVariant), 61 et 17, parce que ça prendra 3 octets au lieu de 12 (voire 18 si tu fais des offsets absolus) [et encore, je ne compte pas le code de passage des arguments] pour un gain en vitesse vraiment négligeable; à vrai dire tu vas même avoir encore d'autres bonnes surprises si tu passes en bytecode, notamment le fait que tu n'as pas à stocker les adresses de retour sur la pile mais dans un registre, etc...

* ce qui sera important, ce ne sera pas tellement le code C généré, mais plutôt la manière dont tu vas allouer tes variables (eh oui, tu vas passer ton tps dans des fonctions d'allocation et de libération), et la qualité de ta bibliothèque de fonctions...


Moi je crois que le fait de générer du code C, ça va juste faire des progs énormes, et ça va t'encourager à ajouter des limitations arbitraires (par exemple, matrices statiques : c le genre de truc tout con mais qui va casser plein de progs qui utilisent seq, ajouter des limites hardcodées, augmenter la consommation en RAM, augmenter le risque d'erreur si on oublie de transformer un "->" en StoMat... bref on ne pourra pas profiter de l'énorme bibliothèque de progs existante)

Bon, tu vas me dire qu'on peut rajouter des déclarations de type explicites et que le code va alors être plus efficace; à la limite, ce que tu peux faire, c'est faire un bloc Native..NativeEnd qui dit que dans ce bloc, toutes les fonctions appelées seront compilées en C... (et dans le bytecode, il y aura juste un tag pour dire d'appeler ce code). Mieux : ça te permettra de faire un compilo on-calc qui, s'il n'y a pas de compilo C, fait comme si les Native..NativeEnd étaient absents

Je ne comprends pas trop la notion "d'inclure" FLib dans Power Basic, en connaissant simplement la syntaxe des appels, en quoi son code est-il nécessaire ? (si le but est de compiler du basic, les appels n'existeront plus, non ?).

Enfin quoi qu'il en soit, non Vertel ne passera pas en gpl, du moins pas pour l'instant

Flanker :
j'avais déjà réfléchi à un truc de ce genre, et cet obstacle m'avait arrêté (et puis j'ai arrêté le basic, ça a pas mal joué)
le plus simple (je pense) est tout simplement d'interdire les expressions de calcul formel. C'est peut-être un peu violent, mais ça a l'avantage d'être simple.
Sinon, pour le changement de type, tu peux pas déclarer plusieurs variables, genre

3 -> x
"coucou" -> x 

serait transformé en

int x_int = 3;
char[] x_char = "coucou\0";

?

C'est une bonne idée, à laquelle je n'avais pas pensé, mais j'avais retenu le type Variant :
Variant x;

x = newVariantNum(3);
x = newVariantStr("coucou");

Votre solution est vraiment intéressente, j'ai l'impression quelle est plus performante. Comme j'ai déjà programmé le compilateur pour utiliser le type Variant, je crois que je vais rester avec cependant.

Vertyos :
Enfin quoi qu'il en soit, non Vertel ne passera pas en gpl, du moins pas pour l'instant

Pffffff... toujours à vouloir fractionner la communauté TI#vtf#

Pollux :
Ce n'est pas une très bonne idée de faire un convertisseur Basic -> C :

* le code C va être énorme

Vrai, pour l'instant le type variant cause un overhead de 5000 bytes a peu près. Bon c'est pas optimisé, mais ça augure mal, je suis d'accord.

Pollux
* apparemment, tu ne vas pas faire d'approximation genre "toutes les variables sont des entiers 16 (ou 32) bits", donc ça va limiter énormément ce que tu peux gagner

Effectivement, les Variant numériques sont des float, dont la manipulation est assez lente, mais tout de même beaucoup plus rapide qu'en basic interprété. Cependant, on peut déclarer une variable comme étant d'un type C particulier. Ex :
New titi As long

Pollux
(à moins de faire une analyse statique de type assez coton ) donc "While x<y:x+1->x:EndWhile" sera transformé en "while (CompareVariant(x,y)<0) x=AddVariant(x,CreateInteger(1));", ce qui fait que tu perds vraiment tout le bénéfice du C : si c'est juste pour que ton code C ressemble à des "jsr CompareVariant", "jsr AddVariant" et "jsr CreateInteger", alors ce sera probablement aussi efficace en tps et plus efficace en vitesse de passer par un tableau qui va contenir 42 (index de CompareVariant), 61 et 17, parce que ça prendra 3 octets au lieu de 12 (voire 18 si tu fais des offsets absolus) [et encore, je ne compte pas le code de passage des arguments] pour un gain en vitesse vraiment négligeable; à vrai dire tu vas même avoir encore d'autres bonnes surprises si tu passes en bytecode, notamment le fait que tu n'as pas à stocker les adresses de retour sur la pile mais dans un registre, etc...

En effet compareVariant(x,y) existe et c'est peu performant. Là dessus c'est exacte qu'un programme Power Basic ne peut pas se comparer à un programme C ou Moka. Cependant, le gain de vitesse viendra de la compilation au lieu de l'interprétation. En appelant directement la fonction compareVariant, je crois qu'il y a un gain considérable par rapport à parser cela :
x < y
Comme je suis pas callé en assembleur (j'ai fais un peu d'assembleur MVS, c'est loin du motorola 68K), j'ai pas très bien suivi tes explications au sujet du tableau pour les comparaisons.

Pollux
* ce qui sera important, ce ne sera pas tellement le code C généré, mais plutôt la manière dont tu vas allouer tes variables (eh oui, tu vas passer ton tps dans des fonctions d'allocation et de libération), et la qualité de ta bibliothèque de fonctions...

Allocation strictement statique de mémoire (les tableaux peuvent être redimensionnés, cependant), pas très puissant, adieux les
totoFunc([[12, 44][543,7]])
mais c'est rapide.

Pollux
Moi je crois que le fait de générer du code C, ça va juste faire des progs énormes, et ça va t'encourager à ajouter des limitations arbitraires (par exemple, matrices statiques : c le genre de truc tout con mais qui va casser plein de progs qui utilisent seq, ajouter des limites hardcodées, augmenter la consommation en RAM, augmenter le risque d'erreur si on oublie de transformer un "->" en StoMat... bref on ne pourra pas profiter de l'énorme bibliothèque de progs existante)

Je ne crois pas que le Power Basic ait une quelconque utilité pour un programmeur C ou Java. Le 'public' visé est les programmeurs basic qui veulent compiler des programmes plus rapides.

Pollux
Bon, tu vas me dire qu'on peut rajouter des déclarations de type explicites et que le code va alors être plus efficace; à la limite, ce que tu peux faire, c'est faire un bloc Native..NativeEnd qui dit que dans ce bloc, toutes les fonctions appelées seront compilées en C... (et dans le bytecode, il y aura juste un tag pour dire d'appeler ce code). Mieux : ça te permettra de faire un compilo on-calc qui, s'il n'y a pas de compilo C, fait comme si les Native..NativeEnd étaient absents

Comme dit dans un post précédent, un bloc Native...EndNative est déjà implémenté. Pour l'instant, je ne prévois pas porter le convertisseur on calc, mais je serais plus que contant si quelqu'un voullait le faire.

Merci pour vos commentaires, je vais poster un alpha d'ici ce soir (heure du Québec), comme ça vous pourrez avoir une meilleure idée de ce qui a été fait. Je sais que plusieurs d'entre vous sont d'excellent programmeurs et que la plupart d'entre vous connaissent mieux l'ASM ou TIGCC que moi. Ce projet est open source, donc si quelqu'un veut y participer, il est le bienvenue.