basc89, Compilateur/Translateur TI-basic -> C - Page 1

Voila, tout est dans le titre, quelques petits exemples de code déja générés:

Prgm
0»x
x+3»y
For x,1,10
"Nombre: "&string(x)»s
PxlText s,1,1
Pause
EndFor
EndPrgm

donne

// Code source C
// Créé par basc89, Limmt Ribeman © 2005

#include <tigcclib.h>

char *strbuf=NULL;
char *strbuf2=NULL;
char *strs=NULL;
float y=0;
short x=0;
char *s=NULL;

void _main (void)
{
  strs=malloc(25);
  x=0;
  y=x+3;
  for(x=1;x<=10;x++)
  {
    if(strbuf) free(strbuf);
    strbuf=malloc(9);
    strcpy(strbuf,"Nombre: ");
    strbuf2=malloc(strlen(strbuf)+3);
    strcpy(strbuf2,strbuf);
    sprintf(strs,"%d",x);
    strcat(strbuf2,strs);
    free(strbuf);
    strbuf=strbuf2;
    s=malloc(strlen(strbuf)+1);
    strcpy(s,strbuf);
    DrawStr(1,1,s,A_REPLACE);
    ngetchx();
  }
  free(strs);
  if(strbuf) free(strbuf);
  strbuf=NULL;
  if(s) free(s);
  s=NULL;
}

et

Prgm
ClrDraw
20»x
PxlText "Test",10,x
For x,1,157
PxlOn 5+x/3,x
EndFor
Pause
EndPrgm

donne

// Code source C
// Créé par basc89, Limmt Ribeman © 2005

#include <tigcclib.h>

char *strbuf=NULL;
char *strbuf2=NULL;
char *strs=NULL;
short x=0;

void _main (void)
{
  strs=malloc(25);
  clrscr();
  x=20;
  DrawStr((short)(x),10,"Test",A_REPLACE);
  for(x=1;x<=157;x++)
  {
    DrawPix((short)(x),(short)(5+x/3),A_NORMAL);
  }
  ngetchx();
  free(strs);
  if(strbuf) free(strbuf);
  strbuf=NULL;
}

vu que c automatisé, tu devrais au moins vérifier tes allocations etc.

Ok

c'est tous des programmes automatiquement générés ? si oui, pk est-ce que y est float alors que x est short ?

y est float car la détection automatique du type n'est pas encore terminée, il voit x+3 et il n'arrive aps encore à derterminer que c'est un short masi ca va venir.
Pour l'instant il fait ca:
Par exemple si tu met:
2->x
3.1->y
il y aura:
short x;
float y;

C'est utilisable oncalc ?

Non comment veux tu qu'une projet TIGCC se compile oncalc :/

Bah moi ca m'serait bien utile
Mais bon, je peux toujours transferer mes progs basics sur le pc et les convertir
#flemme# inside ^^

ya des optimisations au niveau du code prévu lorsque c'est possible???

Quoi comme optimisations par exemple?
Por la compatibilité, le code généré est forcément lourd

Bah deja si ca marche j'trouve ca bien
On lui demandera la lune apres

limmt :
y est float car la détection automatique du type n'est pas encore terminée, il voit x+3 et il n'arrive aps encore à derterminer que c'est un short masi ca va venir.

ok, donc tu fais bien de l'inférence de type, c'est bien, ça
Comment comptes-tu gérer le typage des listes ? (sachant qu'en basic, pour pallier à l'absence de struct{}, c'est courant de mélanger différents types dans une même liste)

limmt :
Non comment veux tu qu'une projet TIGCC se compile oncalc :/

... nooooo ... must ... resist ... tentation ...

mais ton programme, lui, pourrait s'exécuter on-calc ou c'est pas envisageable ?

Ben le programme généré et compilé oui. Le programme qui transforme le code basic, peut être mais ca laguerait beaucoup (aucune optimisation en vitesse) et il faudrait quand meme un peu transformer je pense

Pour les listes, elles seront remplacées par des listes chaines, avec chaque fois un pointeur vers une variable de type variable.

Pour les listes, elles seront remplacées par des listes chaines, avec chaque fois un pointeur vers une variable de type variable.

C'est pas possible avec des tableaux de chaînes ?

Pollux :
...

limmt :
Non comment veux tu qu'une projet TIGCC se compile oncalc :/

... nooooo ... must ... resist ... tentation ...

mais ton programme, lui, pourrait s'exécuter on-calc ou c'est pas envisageable ?

J'ai pas osé

limmt :
Ben le programme généré et compilé oui. Le programme qui transforme le code basic, peut être mais ca laguerait beaucoup (aucune optimisation en vitesse) et il faudrait quand meme un peu transformer je pense

Vraiment génant le "lag" ? Si c'est long a "transformer" je pense pas que ca pose bcp de soucis etant donné que des progs basics de 30ko on en pond pas toutes les 3 minutes

(En tk ce serai dommage de nous priver d'une version oncalc )

Si t'arrives à faire un bon compliateur Limmt, ce sera révolutionnaire

De toutes facons c'est pas possible

Je vais jouer l'avocat du diable, mais est-ce que tu es bien sûr que ça apportera quelque chose par rapport à l'exécution en basic natif ? Est-ce tu sais exactement ce qui rame en basic et qui serait plus optimisé après une passe par ton traducteur ?

Heu...dis moi si je me trompe ExtendeD, mais, le code ti-basic tokénisé n'est pas executable si ? Donc pour executer ce code tokénisé il faut un interpreteur ---> lenteur du basic non ?
Alors que là, Limmt fait un transcodeur ti-basic (source) -> C (source) puis le compile pour en faire un executable. Enfin, c'est ce que j'ai compris...dites moi si je me trompe ^^

optimisation sur les types (short, long, etc...)
c'est vrai que les optimisations ne me viennent pas la comme ca
mais j'avais lu un truc sur des boucles qui dans certains cas en les modifiant legerement par rapport a la boucle traditionnelle était plus rapide

ExtendeD> même en utilisant des algorithmes naïfs comme strlen() et des listes chaînées, ça sera tjs plus rapide que les next_expression_index() du TIOS... maintenant c'est sûr que ça risque d'être très nettement moins performant que du C ou même un interpréteur bien écrit (avec des structures de données plus évoluées), mais c'est tjs mieux que rien ^^


limmt> euh sinon par rapport au typage tu n'as pas peur qu'avec un typage aussi grossier pour les listes, 90% des variables se retrouvent avec un type "variable" et que donc l'inférence de type n'apporte rien ? (parce que si tu fais somme+tableau[i]->somme, tu dois connaître le type de tableau[i] pour savoir quel type d'addition effectuer, sinon "somme" se retrouvera elle aussi avec un type variable, et ainsi de suite pour toutes les variables qui dépendent de "somme" :/)

Pollux : ok Je demande à voir quand même (et ça dépend qu'est-ce qu'on code avec).

Pollux > somme+tableau[i] est forcément une opération arithmétique, donc c'est forcément un nombre, il est impossible d'additionner une chaine de caractères ou une liste

et pour le oncalc, je vois pas vraiment l'intéret de créer un code source et un porjet TIGCC oncalc pour ensuite le remettre sur rodi pour le compiler

pense qu'il pourrait y avoir un jour (lointain) un compilo C on-calc ^^

100% compatible avec TIGCC?
oué mais d'ici à 2042 y'aura bien le temps d'adapter mon programme oncalc

limmt :
Pollux > somme+tableau[i] est forcément une opération arithmétique, donc c'est forcément un nombre, il est impossible d'additionner une chaine de caractères ou une liste

Ben oui, mais tu sais pas si c'est un flottant ou un entier...

limmt> de toute façon tu est loin d'utiliser 100% des features de TIGCC, donc c'est pas un pb.

Pollux > effetivement
je vois pas comment gérer ca autrmeent qu'en différenciant les cas dans le source généré