Power Basic - Page 2

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

Donc poubelle. scritch scritch scritch.
De toute façon se faire des petits programmes personnalisés avec as
c'est plus rapide.

Vertyos :
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

En fait, le but est de rendre les fonctions de FLIB dirrectement utilisables par les programmeurs Power Basic. Ce sera plus rapide que de l'utiliser en basic, car il n'y aura pas de commandes à interpréter. Pour Vertel, et bien que c'est contre l'esprit de la GPL si l'on peut dire, rien n'empêche quiconque de faire une librairie statique qui pourra être utilisée par les programmeurs Power Basic.

Donc poubelle. scritch scritch scritch.
De toute façon se faire des petits programmes personnalisés avec as c'est plus rapide.

Quesoft
: En fait, le but est de rendre les fonctions de FLIB dirrectement utilisables par les programmeurs Power Basic. Ce sera plus rapide que de l'utiliser en basic, car il n'y aura pas de commandes à interpréter. Pour Vertel, et bien que c'est contre l'esprit de la GPL si l'on peut dire, rien n'empêche quiconque de faire une librairie statique qui pourra être utilisée par les programmeurs Power Basic.

Hmm... Directement utilisable par les programmeurs Power Basic, je ne vois pas trop ce que ça veut dire. Parceque la majorité des fonctions de FLib, comme celles de Vertel, ne sont que des appels directs aux ROM_CALLs correspondant, à quelques exceptions près. Je vois très mal ce que tu veux faire

Vertyos
:

Quesoft
: En fait, le but est de rendre les fonctions de FLIB dirrectement utilisables par les programmeurs Power Basic. Ce sera plus rapide que de l'utiliser en basic, car il n'y aura pas de commandes à interpréter. Pour Vertel, et bien que c'est contre l'esprit de la GPL si l'on peut dire, rien n'empêche quiconque de faire une librairie statique qui pourra être utilisée par les programmeurs Power Basic.

Hmm... Directement utilisable par les programmeurs Power Basic, je ne vois pas trop ce que ça veut dire. Parceque la majorité des fonctions de FLib, comme celles de Vertel, ne sont que des appels directs aux ROM_CALLs correspondant, à quelques exceptions près. Je vois très mal ce que tu veux faire

Alors ce sera des appels direct aux ROM_CALLs !

FLib c'est une partie qui fait la liaison Ti-Basic <-> C, et des ROM_CALLs, Vertel idem. Si tu vires la partie liaison, il reste juste des ROM_CALLs qui n'ont plus grand chose à voir avec la librairie. Je ne comprends toujours pas le rapport

Pour faire suite au post de Pollux qui soulevait les lacunes de Power Basic, voici un tableau que je vais inclure dans le readme.txt et qui explique les carractéristiques de Power Basic.

ASM C Moka TI-BASIC Power Basic
Program runs on all
AMS version / hardware No Yes Yes Yes Yes
Level of language 1 3 4 3 3 '0 is machine, 1 is assembled, 2 is not structured imperative, 3 is procedural and 4 object oriented
Compiled Yes Yes Yes No Yes
Speed 1 2 2 4 3 '1 is best, 4 is worst
Effiency (size) 1 2 3 2 4 '1 is best, 4 is worst
Typeless N/A No No Yes Yes
Support types No Yes Yes No Yes
Object oriented No No Yes No No
Support of DLLs Yes Yes Yes No No
C interoperability N/A Yes! Yes No Yes
Creating DLLs Yes Yes No No No
Symbolic manipulation No No No Yes No
User dynamic allocation Yes Yes Yes No Yes*
Memory management User User User** Automated Automated

*Supported thru C interoperability - not garbage collected - :
Native
void *my_storage = malloc(SIZE_TO_ALLOC);
EndNative

**Not using Use_GarbageCollection interface.

ok, le tableau ne sort pas très bien Je crois que les personnes intéressées devront donwloader l'alpha et lire le read me.

Vertyos :
FLib c'est une partie qui fait la liaison Ti-Basic <-> C, et des ROM_CALLs, Vertel idem. Si tu vires la partie liaison, il reste juste des ROM_CALLs qui n'ont plus grand chose à voir avec la librairie. Je ne comprends toujours pas le rapport

Le but est simplement de fournir aux programmeurs l'interface nécessaire pour utiliser ces fonctionnalités. Ex : imaginons que dans TotoLib la fonction imprimeStp() fait un printf. Un programmeur de TotoLib qui arrive en C ne sais pas quelle fonction invoquer. Pour 'inclure' TotoLib, je dois permettre au programmeur d'invoquer imprimeStp. Il y aura donc la définition suivante d'ajoutée :
#define imprimeStp(s) printf(s)

C'est simplement pour rendre service au programmeur.

Je dois avoir un problème, je ne vois toujours pas le rapport avec une interface basic<->C... Peu importe, j'ai l'impression qu'on tourne en rond là

Vertyos>par exemple, si g bien compris, pour FLib, si dans le code Basic, y a flib("drawstr:20,10, str") serat remplacer par le code C de FLib.

Kitsune>compares for t,1,1000:flib("drawstr:20,10,test"):endfor et for t,1,1000utput 10,20,"test":endfor
Et tu peut comparer n'importe quel fonction équivalente (il n'y a que map qui est plus rapide que cyclepic).

Quesoft>Est-ce que ce serat un simple convertisseur ou y aura une IDE avec ??
Pasque du coté IDE, y a TI-Edit, de lOtR qui existe et qui est sous gnu/gpl.

MacIntoc
: Vertyos>par exemple, si g bien compris, pour FLib, si dans le code Basic, y a flib("drawstr:20,10, str") serat remplacer par le code C de FLib.

Bah dans ce cas-là, c'est bien ce que je disais au départ : quelle importance que ce soit le code de FLib ou pas (de toutes façons ça pourra pas être le code de FLib vu qu'il est prévu pour du basic) qui fait le remplacement, d'autant plus que le "code" en question n'est souvent qu'un simple ROM_CALL ?

MacIntoc :
Vertyos>par exemple, si g bien compris, pour FLib, si dans le code Basic, y a flib("drawstr:20,10, str") serat remplacer par le code C de FLib.

Kitsune>compares for t,1,1000:flib("drawstr:20,10,test"):endfor et for t,1,1000utput 10,20,"test":endfor
Et tu peut comparer n'importe quel fonction équivalente (il n'y a que map qui est plus rapide que cyclepic).

Quesoft>Est-ce que ce serat un simple convertisseur ou y aura une IDE avec ??
Pasque du coté IDE, y a TI-Edit, de lOtR qui existe et qui est sous gnu/gpl.

J'ai déjà un IDE (bon, il est pas impressionant), mais je vais regarder TI-Edit...

[EDIT]
Ouais, l'IDE de TI-Edit es plus sexy que le mien !

Bah... en gros, la même chose que ce qui différenci FLib et Vertel, si on oublis la taille et la vitesse des 2 libs

Je crois que tu fais une grosse erreur dans tes choix architecturaux : dans ce que tu désignes comme les gains de Power Basic, tu fais un amalgamme entre :

g1. le gain d'un langage où on n'a pas à parser le programme à chaque instruction (c'est ce que font les casios, mais le ti-basic est plus efficace que ça)
g2. le gain d'un interpréteur écrit par des gens autres que ceux de TI (qui lui est énorme )
g3. le gain du passage d'un bytecode interprété à un code compilé en C

Grosso modo, j'essaye de te dire que seuls g1 et g2 sont intéressants, et que g3 n'est pas significatif -- sauf pour des boucles particulières si on veut faire un prog très optimisé, mais alors la solution des blocs Native permet de garder cet avantage tout en évitant le gros inconvénient de g3 : la taille du code généré...

Et on peut très bien faire un interpréteur de bytecode avec g1 et g2... (et il y aura une compilation comme pour un prog C, sauf que le résultat ne sera pas de l'assembleur 68000)

Quesoft
:

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.

Je ne parle pas de l'overhead fixe, parce qu'on n'y peut rien. Je parle de l'overhead variable, i.e. de la différence de taille une fois compilé entre un prog dont la source fait 10ko et un dont la source est vide... Tu auras vite fait de te retrouver avec un programme 3-4x plus gros que l'original, et c'est un facteur qu'on ne peut pas du tout négliger -- surtout si le prog initial fait 50ko...

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é.

Alors là tu confond ma critique (qui portait sur le fait que g3 ne serait pas très élevé) avec le gain apporté par g2...
Au fait, tu ne manipules *que* des floats ou tu as comme le TIOS une distinction entiers/fractions/floats ? Sachant que si tu ne manipules que des floats, encore une fois tu vas avoir des bugs subtils qui pourront apparaître, par exemple tu peux te retrouver à comparer 0.999999999999 avec 1 (qui sont différents), chose qui ne se serait pas produite avec des entiers ou des fractions...

Cependant, on peut déclarer une variable comme étant d'un type C particulier. Ex : New titi As long

Oui, je suis d'accord. Mais on a la solution des blocs "Native".

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

Là, tu me parles de g1, alors que je critiquais g3, tant du point de vue du faible gain de performance que du point de vue de la grosse perte en taille.

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.

Bon, alors je vais te dire ce que ça donne en C.
Lorsqu'en C, tu appelles compareVariant(x,y), ça te prend environ une bonne dizaine d'octets.
L'idée, c'est de représenter ton code par une suite d'octets (d'où le nom de "bytecode"), avec par exemple :
enum { STOP_TAG=0, COMPARE_TAG=1, STORE_TAG=2, X_TAG=64, Y_TAG=65, ... };
Ensuite, tu crées un tableau d'octet en C
char bytecode[] = { X_TAG, Y_TAG, COMPARE_TAG };
et ton interpréteur va faire

char *bytecode_ptr;
while (*bytecode_ptr!=STOP_TAG) {
  switch (*bytecode_ptr++) {
    case X_TAG: push(variables[0]); break;
    case Y_TAG: push(variables[1]); break;
    case COMPARE_TAG:
      Variant x=pop(),y=pop();
      push(compareVariant(x,y));
      break;
  }
}

comme ça, tu as un code largement plus petit (ici, 3 octets), et l'overhead n'est finalement pas énorme si tu te dis que la majorité du temps sera de toute façon passée dans compareVariant.

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.

Y compris pour les listes ?

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.

J'ai parlé de programmeurs C ou Java ? Je dis juste que Power Basic ne pourra malheureusement pas marcher avec les programmes existants et qu'il faudra un énorme boulot de conversion pour les faire marcher, et c'est un petit peu dommage... Surtout que dans le cas précis de l'allocation statique des matrices/listes, je ne vois pas trop ce que ça peut t'apporter...

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.

Hmm, ma signification du Native...EndNative tel que je le concevais était plutôt pour distinguer le Basic interprété et le Basic compilé (pas le Basic compilé et le C compilé); alors remplace tous les "Native" dans mon post par des Compiled..EndCompiled.

Et sinon, à propos des commentaires sur flib : je ne vois pas non plus trop l'intérêt, à moins de viser la compatibilité à 105% avec les progs basic existants, mais ce serait déjà pas mal si tel était ton but de commencer d'abord par rendre le langage 100% compatible (et ce n'est pas très difficile, s'il y a des bonnes bases en-dessous).

Je comprends mieux le point de vue de Pollux, et je ne peux pas dire qu’il a tort. Cependant, l’objectif de Power Basic est d’améliorer la rapidité d’exécution des programmes basic et non de produire un code plus efficient (les programmes basic sont à la base assez petits, de toutes façons). En plus, un compilateur est plus compliqué à implémenter qu’un convertisseur et en plus, il me faudrait un interpréteur de byte codes, comme on l’a déjà soulevé. Je ne dis pas que c’est une mauvaise idée, mais ce n’est pas ce que je cherche à faire.

Je crois que tu fais une grosse erreur dans tes choix architecturaux : dans ce que tu désignes comme les gains de Power Basic, tu fais un amalgamme entre :

g1. le gain d'un langage où on n'a pas à parser le programme à chaque instruction (c'est ce que font les casios, mais le ti-basic est plus efficace que ça)
g2. le gain d'un interpréteur écrit par des gens autres que ceux de TI (qui lui est énorme )
g3. le gain du passage d'un bytecode interprété à un code compilé en C

Grosso modo, j'essaye de te dire que seuls g1 et g2 sont intéressants, et que g3 n'est pas significatif -- sauf pour des boucles particulières si on veut faire un prog très optimisé, mais alors la solution des blocs Native permet de garder cet avantage tout en évitant le gros inconvénient de g3 : la taille du code généré...

Et on peut très bien faire un interpréteur de bytecode avec g1 et g2... (et il y aura une compilation comme pour un prog C, sauf que le résultat ne sera pas de l'assembleur 68000)

Moi c’est le g1 et g3 qui m’intéressent le plus. Un interpréteur de byte code règle g1 pas g3. Je ne serais pas prêt à dire que je suis meilleur que les gens de TI techniquement, mais je crois qu’un compilateur libre est préférable à un interpréteur propriétaire.

Je ne parle pas de l'overhead fixe, parce qu'on n'y peut rien. Je parle de l'overhead variable, i.e. de la différence de taille une fois compilé entre un prog dont la source fait 10ko et un dont la source est vide... Tu auras vite fait de te retrouver avec un programme 3-4x plus gros que l'original, et c'est un facteur qu'on ne peut pas du tout négliger -- surtout si le prog initial fait 50ko...

Les langages qui compilent en byte code produisent des ‘exécutables’ généralement plus petit que ceux des langages compilés. Cependant, je crois que le 3-4x plus gros est exagéré. Le overhead viens principalement du support du type Variant, qui est une calamité, mais qui se retrouve dans tous les basic. Encore une fois, le but que je vise n’est pas d’atteindre l’efficience de l’assembleur, mais de permettre de programmer des programmes basic qui soient rapides.

Au fait, tu ne manipules *que* des floats ou tu as comme le TIOS une distinction entiers/fractions/floats ? Sachant que si tu ne manipules que des floats, encore une fois tu vas avoir des bugs subtils qui pourront apparaître, par exemple tu peux te retrouver à comparer 0.999999999999 avec 1 (qui sont différents), chose qui ne se serait pas produite avec des entiers ou des fractions...

C’est vrai, mais je crois que ça vaut l’amélioration des performances que cela génère. J’ai pas beaucoup d’expérience en VB, mais je crois pas que VB supporte les fractions non plus. Tout ça pour dire que le Power Basic ne sera pas adapté pour faire des manipulations algébriques. Le Power Basic vise à offrir aux programmeurs la puissance d’un langage compilé.

Bon, alors je vais te dire ce que ça donne en C.
Lorsqu'en C, tu appelles compareVariant(x,y), ça te prend environ une bonne dizaine d'octets.
L'idée, c'est de représenter ton code par une suite d'octets (d'où le nom de "bytecode"), avec par exemple :
enum { STOP_TAG=0, COMPARE_TAG=1, STORE_TAG=2, X_TAG=64, Y_TAG=65, ... };
Ensuite, tu crées un tableau d'octet en C
char bytecode[] = { X_TAG, Y_TAG, COMPARE_TAG };
et ton interpréteur va faire

char *bytecode_ptr;
while (*bytecode_ptr!=STOP_TAG) {
  switch (*bytecode_ptr++) {
    case X_TAG: push(variables[0]); break;
    case Y_TAG: push(variables[1]); break;
    case COMPARE_TAG:
      Variant x=pop(),y=pop();
      push(compareVariant(x,y));
      break;
  }
}

comme ça, tu as un code largement plus petit (ici, 3 octets), et l'overhead n'est finalement pas énorme si tu te dis que la majorité du temps sera de toute façon passée dans compareVariant.

Je suis d’accord que le overhead est minime, mais je persiste à croire que la vitesse ne pourra toujours pas se comparer à celle d’un langage compilé. J’ai essayé la machine virtuelle waba sur ma TI-92. J’ai été impressionné par l’interpréteur de byte code, c’était une belle prouesse technique, mais la vitesse d’exécution était atrocement lente. Le convertisseur Java à C Moka est une poubelle par rapport à waba (bon, une poubelle pas trop laide tout de même), côté technique, mais les programmes qu’il produit, bien qu’énormes par rapport à leurs équivalents waba, sont rapide au point où ils peuvent se mesurer à ceux programmés en C. Bien sûr, le Power Basic ne pourra pas produire des programmes aussi efficients, mais on va pouvoir s’en rapprocher.

Y compris pour les listes ?

J’ai fais un compromis (en fait, j’ai pris la solution la plus simple) :
On déclare statiquement la matrice, mais on la réalloue dynamiquement quand on veut.
‘ Declaration
NewMat mtoto, 33, 44
‘Changer la taille
ReDim mtoto, 10, 10

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)

Effectivement, les progs vont être assez gros. Mais le mécanisme d’allocation des matrices permettra d’éviter le piège dont tu parles. Pour la bibliothèque existante, un
SHELL MONPROG()
Permettra de les exécuter.

J'ai parlé de programmeurs C ou Java ? Je dis juste que Power Basic ne pourra malheureusement pas marcher avec les programmes existants et qu'il faudra un énorme boulot de conversion pour les faire marcher, et c'est un petit peu dommage... Surtout que dans le cas précis de l'allocation statique des matrices/listes, je ne vois pas trop ce que ça peut t'apporter...

Le boulot de conversion, sans être énorme, sera substantiel, c’est vrai. Cependant, les programmes actuels n’ont pas à être converti en PB. Un programmeur basic pourra programmer en PB sans trop se casser la tête, c’est ça le but visé.

Hmm, ma signification du Native...EndNative tel que je le concevais était plutôt pour distinguer le Basic interprété et le Basic compilé (pas le Basic compilé et le C compilé); alors remplace tous les "Native" dans mon post par des Compiled..EndCompiled.

J’avais mal compris le sens de tes blocs natifs, désolé. Mes blocs natifs permettent de coder du C ’in stream’ si l’on puis dire. Ex :

‘je programme en basic
Native
/* Je suis en C */
printf(‘’hello world!’’) ;
EndNative
‘je continue en basic


En conclusion, je reconnais que ton design est plus propre. Cependant, je crois qu’il est plus facile d’implémenter les miens et qu’en plus, un langage compilé (en fait je devrais dire qui produit des programmes natifs) sera plus rapide qu’un langage interprété.

Cependant, comme toujours, c’est open source et si tu es intéressé à programmer ton interpréteur de byte code et même à le greffer au projet pour offrir aux programmeurs plus de contrôle sur la façon dont sera compilé leur programme, ce n’est pas moi qui vais t’en empêcher.

Merci encore.

Pollux
: Et sinon, à propos des commentaires sur flib : je ne vois pas non plus trop l'intérêt, à moins de viser la compatibilité à 105% avec les progs basic existants, mais ce serait déjà pas mal si tel était ton but de commencer d'abord par rendre le langage 100% compatible (et ce n'est pas très difficile, s'il y a des bonnes bases en-dessous).

En fait, si les commandes FLIB correspondent dirrectement aux fonctions de la TIGCCLIB et quelles portent le même nom, il n'y aurra pas de travail à faire pour l'<incorporer>.

Pour les réallocation, tu fait une différence entre redim var(size) et redim preserve var(size) ??

MacIntoc
: Pour les réallocation, tu fait une différence entre redim var(size) et redim preserve var(size) ??

Si
redim preserve var(size)
préserve le contenu de la matrice et bien la réponse est non. Les réallocations préservent le contenu du tableau. Cependant, si pour des raisons de performances quelqu'un en ait vraiement de besoin de réallocation sans préservation, alors il est possible de le faire.

Bah... perso, je préfères avec preservation du contenu, c moins long à taper

MacIntoc :
Bah... perso, je préfères avec preservation du contenu, c moins long à taper

Tant mieux, c'est ce qui est implémenté pour l'instant.

Oula, un langage encore plus lent et gros que Moka?
Je ne comprends pas trop l'intérêt: les programmes TI-BASIC ne seront pas utilisables avec Power Basic en vue de toutes les différences, donc ça sert à quoi? Il vaut mieux programmer en C, c'est beaucoup plus adapté au support...
Et je te signale qu'il existe déjà un langage appelé "PowerBASIC" (sur PC).

typosquaaaaaat !

Kevin Kofler :
Oula, un langage encore plus lent et gros que Moka?

Moka est gros, oui, toute proportion gardée (et bien qu'avec le MDK 2.2, c'est plus si vrai si on utilise pas l'OO). Dire qu'il est lent, par contre, c'est de la diffamation ! De toute façon, est-ce que tu as déjà utilisé un poduit avant de le critiquer ? Moi je dénigre bien VB, mais au moins je l'ai déjà essayé avant d'en parler.

Kevin Kofler :
Je ne comprends pas trop l'intérêt: les programmes TI-BASIC ne seront pas utilisables avec Power Basic en vue de toutes les différences, donc ça sert à quoi?

Comme la syntaxe PB est identique à la syntaxe TI-BASIC, un programmeur basic pourra programmer sans avoir à apprendre un nouveau langage. C'est ça l'intérêt.

Kevin Kofler :
Il vaut mieux programmer en C, c'est beaucoup plus adapté au support...

Vrai, mais ce n'est pas tout le monde, comme je l'ai déjà soulevé, qui désirent apprendre le C.

Kevin Kofler
: Et je te signale qu'il existe déjà un langage appelé "PowerBASIC" (sur PC).

Je ne le savait pas. J'espère que PB deviendra pas trop populaire, pour éviter les poursuites ...

[EDIT]

À quoi ça sert : Je pense que plusieurs programmeurs restent avec le basic parce qu'il est non typé et surtout qu'il n'y a pas de gestion de la mémoire. Power Basic permet à ces programmeurs d'améliorer considérablement la rapidité de leurs programmes, sans avoir à ce casser la tête.

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";

?

J'ai repensé à cette architecture et j'ai réalisé qu'il y aurait un problème lorsque viendrait le temps de faire une opération comme

x -­> y

comment choisir entre x_int et x_char. Ça reste une bonne idée, par contre.

Vous pouvez maintenant télécharger un build de Power Basic :
http://quesoft.dyndns.org:8080/dev/pbasicalpha.zip

Ainsi, vous aurez une meilleure idée du travail effectué jusqu'à présent.

Voici le mode d'emploi :

- Démarrez PBasic.exe

-Faites fichier -> new program. Vous n'êtes pas obligé de fournir une liste de paramètre.

- Tapez le programme suivant :
PName()
Prgm
ClrScr
Disp "Hello World !"
Pause
EndPrgm

- Faites convert -> convert to TIGCC project

- Sauvegardez votre fichier source dans un répertoire facilement accessible.

- Appuyez sur convert !

- Exécutez le .tpr dans le sous répertoire créé par la conversion (vous devez avoir TIGCC 0.95 d'installé) puis compilez le tout.

- Transférez et exécutez.

Pour que l'écran soit restauré après l'exécution modifier le programme comme suit :
PName()
Prgm
Option SaveScreen
ClrScr
Disp "Hello World !"
Pause
EndPrgm

Pour afficher une string fournie en paramètre, modifiez votre programme comme suit :
PName(str)
Prgm
Option SaveScreen
ClrScr
Disp str
Pause
EndPrgm


Comme toujours, je suis ouvert à vos commentaires ...

Je ne suis pas vraiment convaincu de l'utilité de la chose si ça ne permet pas de réutiliser les progs existants, mais bon...

Sinon, comment gères-tu ta mémoire ? Tu passes par les fonctions du TIOS ? ()


./55> surtout, ce genre d'analyse statique de type va se mettre à foirer complètement lorsqu'on fera des listes (qui peuvent mélanger des types différents, et jouent donc un peu le rôle des structures en C), et ça deviendra impossible de faire le moindre typage... d'ailleurs comment fait on dans Power Basic pour définir une liste d'élements qui sont des listes contenant 3 entiers et une chaîne ? (sans passer par des Variant)

Pollux :
Je ne suis pas vraiment convaincu de l'utilité de la chose si ça ne permet pas de réutiliser les progs existants, mais bon...

Sinon, comment gères-tu ta mémoire ? Tu passes par les fonctions du TIOS ? ()


./55> surtout, ce genre d'analyse statique de type va se mettre à foirer complètement lorsqu'on fera des listes (qui peuvent mélanger des types différents, et jouent donc un peu le rôle des structures en C), et ça deviendra impossible de faire le moindre typage... d'ailleurs comment fait on dans Power Basic pour définir une liste d'élements qui sont des listes contenant 3 entiers et une chaîne ? (sans passer par des Variant)

En fait, comme tu peux le voir, les différences sont très légères. Quant aux listes, elles sont implémentées comme des array de Variant.

OK, je viens d'essayer, c pas mal, mais :

#ifndef VARIANT_STRING_SIZE
	#define VARIANT_STRING_SIZE 256
#endif

typedef enum {VARIANT_UNDEFINED, VARIANT_NUMERIC, VARIANT_STRING, VARIANT_POINTER, VARIANT_ARRAY} Variant_Type;

struct Variant_Struct;

struct VariantArray_Struct;

typedef struct Variant_Struct {
	union {
		double num;
		char str[VARIANT_STRING_SIZE]; // <---------------------- #eeek#
		struct Variant_Struct * ptr;
		void * voidp;
	};
	struct VariantArray_Struct * array;
	Variant_Type type;
} Variant;

Au moins tu n'es pas trop posé de pbs de conscience pour la gestion de la mémoire Non seulement le prog plante dès qu'une chaîne fait plus de 256 caractères, mais en plus n'importe quel entier non spécifiquement déclaré comme Short prend plus de 256 octets !!!

Au moins tu n'es pas trop posé de pbs de conscience pour la gestion de la mémoire Non seulement le prog plante dès qu'une chaîne fait plus de 256 caractères, mais en plus n'importe quel entier non spécifiquement déclaré comme Short prend plus de 256 octets !!!

Essaie Option StringSize 1024 pour les string (cette option n'est pas testée à fond cependant). As-tu un exemple pour les entiers, je ne comprend pas comment un entier peut prendre plus de 256 octets ... à moins que ce que tu veux dire est que sa représentation prend plus de 256 octets ? Si c'est le cas, c'est que ça dépasse la capacité du type float.

PName(str)
Prgm
Option StringSize 1024
Option SaveScreen
ClrScr
Disp str
Pause
EndPrgm

OK, je viens d'essayer, c pas mal, mais :

Il faut pas oublié que c'est même pas une version alpha encore ... Je sais qu'avoir mis la mémoire pour acceuillir la string dirrectement dans la structure c'est pas très efficace et que ce serait facile de dépasser les 64 k si on met un string size trop gros, mais j'ai fais ça pour simplifier l'implémentation et avoir rapidement quelque chose de fonctionnel.