Librairie BASIC... spéciale! - Page 1

Ben oui, c'est une librairie BASIC assez spéciale que je me suis aventuré à programmer. Le but était à la base de permettre de faire des boucles ou d'analyser des variables entières de façon plus rapide que le BASIC. Je m'explique.
N'étant pas un dieu en programmation, c'est très modeste, mais ça peut donner des idées à ceux qui voudraient vraiment réaliser des libs du style, mais mieux. Voilà un exemple:

lib("Font 2
nA=0
_boucle
cA=nA
DrawStr 0,0,cA
If nA,1000,""<""
Goto boucle")

L'utilisation des commandes est assez simple. Les arguments sont tous facultatifs. Chaque variable est précédée de son type (n ou c) puis de sa lettre (on ne peut leur donner de nom pour l'instant, ce serait trop lent). n c'est entier et c c'est chaîne. Lorsqu'on assigne un entier à une chaîne (ou inversément aussi je crois) la conversion est automatiquement faite. On peut aussi utiliser le format de sprintf pour un assignement, du genre: cA=""%05i"",nA. Notez que les "" sont obligatoires sinon cela fermerait la chaîne. (en BASIC donc) On peut encore utiliser #var pour accéder à la variable BASIC, et j'essaie de permettre aussi l'assignement. On verra encore pour les accès à des matrices et des listes.
La syntaxe des If est catastrophique (en tous cas pour le moment) et cela n'ignore que la prochaine instruction. En gros, les if.. else if.. deviennent aussi compliqués qu'en assembleur. Idem pour les boucles (avec les goto).
If expression1 (entier),expression2 (entier),opérateur (chaîne)
A part ça, la vitesse d'exécution est plutôt mauvaise: (voici un benchmark)
Vitesse en BASIC avec CLIB: 2864
Vitesse avec LIB: 267
Vitesse en C pur: 20
Pour se faire une idée, il s'agissait d'un prog qui remplit deux fois l'écran de lignes en inversé. Pour l'instant tout est clippé, il y a une vingtaine de fonctions, et ça prend moins de 5 ko, avec l'interpréteur et tout... Et la stabilité est bonne, un bon point au moins

Arf tu viens de commencer un truc que je voulais faire depuis un moment, mais à peine ébauché par flemme
Je testerais quand j'aurais un peu de temps [et quand t'auras releasé, j'avais même pas vu qu'il n'y avait pas de lien dans ton post ], peut-être que ça fera venir la motivation

Crois-le ou non Vertyos, mais j'en étais quasiment sûr (ou bien que tu l'avais déjà fait ou bien que ça t'intéresserait) vu le principe de vertel...
Le concept n'a rien d'impressionnant, mais c'est vrai que je n'avais pas mesuré le boulot que ça demanderait. Je l'ai programmé sur CC mais hier j'ai du arrêter car il me plantait à tous les coups à cause de la mémoire (le fichier asm était incomplet). J'avoue qu'après l'avoir passé sur TIGCC je suis plutôt étonné car le code généré par CC n'est pas si mal, loin de là même.

Heu non je ne l'ai pas déjà fait, juste commencé mais c'est totalement inutilisable. Il faudrait que je trouve des docs pour analyser correctement une expression mathématique : je ne voulais pas refaire un langage, mais un interpreteur "partiel" de Ti-Basic, qui comprenne exactement la même syntaxe que celle officielle.
Mais après avoir apprit comment interpreter l'expression, il faudrait réécrire toutes les principales instructions Ti-Basic -> flemme -> "remis à plus tard"

Attention: ce n'est pas mon cas, et je ne sais pas interpréter les expressions! C'est impossible et cela ne le sera jamais (place), tout ce que tu peux faire c'est:
nA=8
nA*GetPix 0,0
nA+10
DrawStr 0,nA,""Le texte sera en bas si le pixel 0,0 est allumé""
En fait c'est du genre '=', '+=', '-=', '*=', "/=", c'est tout.
Et le TI-BASIC n'est pas trop mal codé apparemment, et ça m'étonnerait que tu puisse faire quelque chose de plus d'un virgule cinq fois plus rapide...

C'est un défi interessant à relever

Brunni
: Et le TI-BASIC n'est pas trop mal codé apparemment, et ça m'étonnerait que tu puisse faire quelque chose de plus d'un virgule cinq fois plus rapide...

D'après Pollux, si.

Ce que je ne comprends pas, c'est pourquoi on devrait s'embêter avec ton langage interprété très limité quand on peut programmer en C tout simplement, et avoir des programmes encore plus rapides avec beaucoup plus de fonctionnalités.

Kevin, il y a de ceux qui aimeraient programmer on-calc. En fait il y en a un paquet. Il y en a aussi qui voudraient que leur calculatrice ne plante pas même s'ils ne savent pas programmer. On peut utiliser CC, bien sûr, mais quand il t'aura planté vingt fois parce que tu utilises une variable non-déclarée, ou bien que tu oublies le suffixe long, que tu te gourres d'argument avec un ROM_call, alors là tu en auras marre. Et TIGCC, comme je l'ai dit, tout le monde ne programme pas sur son PC. (j'en suis un exemple)
A part ça, voici un petit comparatif des principales librairies (je n'aurais jamais pensé qu'il puisse y avoir une telle différence). Le prog en question est toujours celui des lignes. J'en fais 100. La syntaxe est dans tous les cas
For a,0,99
<appel de librairie>
EndFor
Je sais que dans toutes ces libs il est possible d'optimiser, mais là ce n'est pas le but. A droite, le temps effectué.
4è. Flib: flib("line:0, a,159, a,2") -> 3629
3è. Clib: cl(5,0,a,159,a,2) -> 2961
2è. Vertel: vertel("line",0,a,159,a,2) -> 2176
1er. Lib: lib("Line 0,#a,159,#a,2") -> 1480
C'est énorme hein? Bon, lib je sais qu'elle sera plus lente lorsqu'elle aura toutes ses fonctions.

Le truc c'est que le bench n'est pas égal : quelqun qui se sert correctement de Vertel n'écrira jamais l'affreuse boucle avec un "for". Refais donc un test avec la gestion de listes pour voir ?

[edit] Si je fais un test avec gestion de liste en restant à ton échelle, je trouve moins de 120 pour Vertel

Comment tu fais pour tes listes Vertyos?
Pour les 120, tu dois faire deux fois, donc 240, voire moins, ça dépend. en optimisé j'ai 290 avec ma lib...
Et je ne sais pas comment tu as mesuré le temps toi!
A part ça, j'ai rajouté le support écriture avec les variables externes (TI-BASIC) de type entier positif et négatif et chaîne. La syntaxe du If est enfin correcte: If expression 1 opérateur expression 2 (If nI<100). J'ai aussi rajouté 21 fonctions inutiles pour tester si plus tard ce sera toujours aussi rapide. Le résultat est toujours correct. (1526 au bench)
Puis il y a encore la fonction sinus. Sin rayon,angle renvoie un nombre entier. J'ai fait un ch'tit prog qui fait un cercle de 30 pixels de rayon en faisant 360 lignes du centre au rayon, et ça se fait en 12 secondes . Mais en BASIC c'est pas la peine de tester (j'en ai déjà marre après 90°) parce que mes piles...
Valà.

Brunni
: Comment tu fais pour tes listes Vertyos?

Comment je fais quoi ?

Pour les 120, tu dois faire deux fois, donc 240, voire moins, ça dépend. en optimisé j'ai 290 avec ma lib...
Et je ne sais pas comment tu as mesuré le temps toi!

J'ai utilisé le timer 6, et fait une regle de 3 pour être sur la même échelle que toi. C'est pas "très" précis mais l'erreur doit être de 10 grand maximum. Pourquoi est-ce que je devrais multiplier par 2

Je fais deux fois le test (deux fois en inversé == restore l'écran initial).

Comment je fais quoi ?

Quel code tu as utilisé pour tester? Ca m'intéresse...

J'ai utilisé le timer 6, et fait une regle de 3 pour être sur la même échelle que toi.

Perso j'ai utilisé le timer programmable poussé à fond (HW2) et le USER_TIMER pour mesurer. En gros:

cl(38,0hff)
cl(22,6,10000)
<Code>
cl(23,6)
Disp "Cela a pris environ "&string(10000-cr[1])&" ticks"
cl(38,0hD0)

Sasume
:

Brunni
: Et le TI-BASIC n'est pas trop mal codé apparemment, et ça m'étonnerait que tu puisse faire quelque chose de plus d'un virgule cinq fois plus rapide...

D'après Pollux, si.

L'auteur du plus gros vaporware de tous les temps? Je veux le voir moi, son basic plus rapide (ne le prends pas mal Pollux hein!)

Brunni
: Quel code tu as utilisé pour tester? Ca m'intéresse...

seq(a,a,0,99)->a
vertel("time",10000)
vertel("line",0,"#a",159,"#a",2)
vertel("time","","retr","a",1)
vertel("stxt","Temps : "&string(10000-a))

• Le seq est volontairement hors de la boucle puisqu'il n'a rien à voir avec les perf de la lib
• Les appels sont séparés sans quoi le test serait faussé (un seul appel serait plus rapide)

Ah ben je ne connaissais pas seq. Mais bon, tu as un petit moment pour exécuter la fonction seq et tu as une monstre liste. (seq a en fait un rapport avec les performances puisqu'il est obligatoire)
Moi je pourrais aussi faire:
"Line 0,#a,159,#a,2"->b
for a,0,99
lib("->b")
endfor
Ou encore mieux:
lib("nA=0
Lbl 0
Line 0,nA,159,nA,2
nA+
If nA<=99
Goto 0")
Comme je pourrais faire:
For a,0,99,2
cl(5,0,a,159,a,2,[infini],5,0,a+1,159,a+1)
EndFor
Ca aussi ce serait bien plus rapide. Je parlais d'un simple petit test pour évaluer les performances de base de la librairie. Ne rêve pas, ce n'est pas avec vertel que tu vas pouvoir faire un If, ce qui peut souvent être le cas pour afficher une série d'éléments. Exemple: tu affiches le type de toutes les variables d'une liste, et si elles ont un type 248 (OTH_TAG), tu fais un test sup. pour avoir l'extension finale. Et bien tu ne feras pas ça avec vertel, à moins de précalculer la liste, ce qui te fais tricher au bench à moins que tu comptes ce temps dedans, et là les résultats seront beaucoup plus pauvres...

Si tu biaise les bench pour être plus rapide, forcément y'aura toujours moyen de caser ta lib au-dessus. Mais bon personne (sauf un newbie) n'écrira d'appel avec des for. Ton premier exemple ne te fera rien gagner du tout.
Au passage, même en incluant le seq dans le bench (ce qui est stupide), Vertel reste plus rapide (190 contre 290).

Tiens au passage personne n'a essayer de faire comme le java du compilé interpreté.
En gros pouvoir faire un nouveau language proche du basic, et pouvoir le compilé et l'interprété par une machine virtuelle.
Je pense que c'est possible et je pense que pollux n'est pas "l'auteur du plus gros vaporware de tous les temps", je pense aussi qu'il a raison.

Brunni :
Exemple: tu affiches le type de toutes les variables d'une liste, et si elles ont un type 248 (OTH_TAG), tu fais un test sup. pour avoir l'extension finale. Et bien tu ne feras pas ça avec vertel, à moins de précalculer la liste, ce qui te fais tricher au bench à moins que tu comptes ce temps dedans, et là les résultats seront beaucoup plus pauvres...

c koi que t'appelle "pré-calculé la liste" ??

mastergb1 :
En gros pouvoir faire un nouveau language proche du basic, et pouvoir le compilé et l'interprété par une machine virtuelle.

C pas ce que Pollux fait avec GT-Basic ??

Je sais pas ce qu'il fait vraiment avec GT-basic.
Mais je pense que c'est faisable.Et etant donné que j'ai aucun projet en cours pourquoi ne pas en commencer un nouveau(ou quitter la communauté ti...).
Yavait longtemps que j'avais aussi comme idée de faire un truc comme ca mais orienté jeux et avec un support genlib.

Peut etre que j'essaierai..

du basic avec genlib

Je pense que c'est possible et je pense que pollux n'est pas "l'auteur du plus gros vaporware de tous les temps", je pense aussi qu'il a raison.

J'éxagérais un peu là, mais j'étais bien impatient...
#18:>Ben traiter la liste hors de ta boucle, comme ça après tu peux l'afficher directement avec vertel...
Sinon c'est vrai que je suis impressionné de la vitesse de vertel... C'est tout bonnement incroyable! Avec mes tests, j'ai 227* pour vertel et 259 pour lib (je l'ai optimisée entre-temps, et étonnemment l'enlèvement de cinq conditions (*pLn!='=' || *pLn!='+' || *pLn!='-' || *pLn!='*' || *pLn!='/') après en avoir rajoutée une autre me fait gagner plus de vingt au bench... et encore, ces conditions ne sont supprimées que pour l'instruction Line...
*j'ai inclus le seq

Si tu biaise les bench pour être plus rapide, forcément y'aura toujours moyen de caser ta lib au-dessus. Mais bon personne (sauf un newbie) n'écrira d'appel avec des for. Ton premier exemple ne te fera rien gagner du tout. Au passage, même en incluant le seq dans le bench (ce qui est stupide), Vertel reste plus rapide (190 contre 290).

Je ne biaise pas les benchs, et le code que je t'ai donné est tout à fait légal et propre pour ma lib, comme tes listes.
Sinon je suis en train de faire un snake en basic avec ma lib. On verra ce que ça donne.

Oui mais par contre tu m'explique que ma méthode de precalc qui est plus rapide que ta lib est, comme par hazard, non valide

Le seq il est à faire une fois au début du programme, et après tu peux appeller 100 fois vertel si ça te chante, la liste ne sera plus à recalculer. C'est pour cette raison que le seq n'est pas à prendre en compte, comme il ne sera pas prit en compte dans la boucle principale d'un jeu.

Brunni
: Sinon c'est vrai que je suis impressionné de la vitesse de vertel... C'est tout bonnement incroyable!

./21> je vais faire une ébauche de projet. et regarder si c'est viable.
Je sais aussi que c'est une honte pour genlib mais peut etre que j'arriverais a des trucs correcte.
Et puis si j fais ce que j'ai envie de faire ca ressemblera en rien au basic.
Ca sera un language nouveau.

Mes sincères encouragements mastergb...
C'est vrai que ce serait bien, et même si ce n'est pas du BASIC. Et je pense que de faire ton propre langage sera beaucoup mieux (pour toi en tous cas, si tu n'arrives pas à faire un truc -> hop! spécialité du langage et ça passe inaperçu )

Vertyos:

Brunni
: Sinon c'est vrai que je suis impressionné de la vitesse de vertel... C'est tout bonnement incroyable!

Franchement c'est vrai.

Brunny>Y a quand même un truc que je comprend pas dans ton exemple, les listes sont générer et traiter par vertel, donc tu peut pas les générer et les traiter hors de vertel ???

Argh... j'ai de GROS problèmes. Faudrait pitet que je bloque le "handle" de la chaîne de caractères que je lis si celle-ci ne se trouve pas sur la pile d'expressions...

Brunny>Y a quand même un truc que je comprend pas dans ton exemple, les listes sont générer et traiter par vertel, donc tu peut pas les générer et les traiter hors de vertel ???

Ben tu dois lui envoyer une liste de valeurs à vertel, pour qu'ils les traite. Cette liste, c'est toi qui la crée en fait.
A part ça mon snake est quand-même ultra-lent et en plus il bugge (mon algo doit être merdique).

Maintenant je sais ce qui ralentit tout, c'est l'assignement dans des variables BASIC. Quelles fonctions me conseilleriez-vous pour faire cela, sachant que je n'utilise pas fopen mais une connerie qui alloue un max puis redimensionne le bloc une fois qu'on ferme le fichier. C'est du *Made in Brünni*, donc ça doit être facile à optimiser, mais là je ne vois pas comment...

Grahh... Tu me donne de plus en plus envie de faire un interpreteur... Quelqun a un tuto pour analyser une expression mathématique ?

Si j'ai bien compris, je peux arrêter mon projet? Le tien sera cent fois plus rapide je pense...
Je plaisante je ne vais pas l'arrêter, mais bon... c'est déloyal
Sinon, y'a-t-il quelqu'un qui peut m'aider pour les fichiers, ou bien faut-il que je crée un topic?
Un heapAlloc(HeapMax()) crée quasi-toujours un HeapCompress, d'où un joli plantage par la suite (rassurez-vous rien d'impressionnant, juste que l'analyseur va s'arrêter car il est perdu et parce qu'il trouvera sûrement un zéro lui indiquant la fin de la chaîne)