compilateur version de travail 0.1 alpha 4

Une nouvelle version de travail du compilateur est disponible sur mon WebDav. C'est une version alpha, donc pas encore utilisable pour la production.

COMPILATEUR V 0.1 alpha 4 : Version du 17 mai 2014, basée sur PANORAMIC V 0.9.25

A - Améliorations :

- correction d'un bug sur TO_FOREGROUND
- correction d'un bug sur PARENT
- codage de NORMAL
- codage de CAM_ROLL, CAM_TURN, CAM_PITCH, CAM_MOVE, POINT_OBJECT
- codage de FILE_READ$(N), FILE_READLN$(N)
- codage de FILE_FIND_CLOSE
- codage de ADR(Variable) *** bien que je n'avais pas prévu de coder cette fonction ***
- codage de FILEBIN_READ(), FILEBIN_HEXA_READ()

B - Contraintes provisoires :

B.1 - le nom du fichier source doit avoir un nom de 64 caractères maximum.
B.2 - l'exécutable généré se trouve dans le répertoire de l'éditeur.

C - Différences avec l'interpréteur :

C.1 - CHAIN
CHAIN agit sur un exécutable et non sur un source.
Si le fichier désigné par CHAIN n’existe pas, il n’y a pas d’affichage d’erreur.

C.2 - PRINT n'accepte ni virgule, ni point virgule.
print "valeur =";a%
est à remplacer par
print "valeur ="+str$(a%)

C.3 - Fichiers TEXTE
FILE_WRITELN N,V n'accepte que des variables V$ chaine de caractères
FILE_READ N,V n'existe plus. Il faut utiliser la fonction V$=FILE_READ$(N)
FILE_READLN N,V n'existe plus. Il faut utiliser la fonction V$=FILE_READLN$(N)

C.4 -Taille d'un tableau défini par une variable
Définir la taille d'un tableau avec une autre variable n'est pas possible. La taille doit être un nombre.

C.5 - Définir des variables de même nom mais de type différent n'est pas accepté.
dim a%,a$,a n'est pas accepté

C.6 - Les variables systèmes suivantes retournent toujours 0 (ce problème sera corrigé ultérieurement) :
KEY_DOWN_CODE
KEY_DOWN_SPECIAL
KEY_UP_CODE
KEY_UP_SPECIAL

C.7 - Ce qui n'est pas complètement codé pour le moment :
PARAM_NUMBER
PARAM_VALUE$()
SCANCODE
INKEY$
PAUSE
EXECUTE
EXECUTE_WAIT
EXIT_FOR
EXIT_WHILE
EXIT_REPEAT
FILE_READBUF
APPLICATION_TITLE
FILE_WRITEBUF
FILE_NAMES_ADD

C.8 - Ce qui ne sera pas implémenté :
NUMBER_CURRENT_LINE
VARIABLE()
LABEL()
TRACE_ON
TRACE_OFF
FREE
PEEK()
POKE
FILEBIN_BLOCK_READ
FILEBIN_BLOCK_WRITE

C.9 - Une erreur de débordement de tableau à l'exécution n'est pas signalée.

C.10 - INPUT fait apparaitre une fenêtre de saisie.

C.11 - A$=123 n'est plus accepté, il faut mettre des guillemets : A$="123"

D _ Bugs connus :

D1 - Redéfinir une nouvelle texture à un objet 3D qui en possédait déjà une provoque un plantage à l'exécution.
D2 - PRINT ADR(Variable) provoque une erreur à la compilation

Merci Jack. Je viens de le récupérer.

J’ai téléchargé, merci Jack

J’ai testé ADR()

Problème avec ADR()
Le code suivant  s’exécute sous l’interpréteur et affiche bien la valeur.

Code:

dim x
x = 1.23456
print adr(x)

Par contre, sous le compilateur : erreur lors de la compilation :

test.bas(86) error 25: Invalid data types, at parameter 1 of sub(byval as double)
pc_print_number(@(V_X))

Bonjour.

Comme il est dit plus haut:

D2 - PRINT ADR(Variable) provoque une erreur à la compilation

est une erreur connue.

Donc, il est normal qu'elle provoque un plantage aujourd'hui !

Personnellement, je vais patienter un peu, histoire que le compilateur soit vraiment opérationnel.

Car mon programme de plus de 27.000 lignes fait un gros usage des commandes "exit_".

Et je ne vois pas comment procéder aujourd'hui pour les simuler.

Donc, patience.

Désolé !

Je n’ai pas lu jusqu’à la fin du post de Jack.  
C’est l’un de mes innombrables défauts    

L'impatience de la jeunesse !

En tout cas, ça continue de bien avancer. Merci Jack

Le code suivant passe très bien en FreeBASIC :

Code:

dim as double x = 1.3456 : print @x

Donc il ne devrait pas être très difficle de corriger le "bug".

Pedro Alvarez a écrit:

Car mon programme de plus de 27.000 lignes fait un gros usage des commandes "exit_".

Il n'est pas très difficile de simuler un exit, le problème c'est les 27000 lignes de code. Cela fait un peu beaucoup.

Code:

' pour simuler exit_xxx

for()
while()

end
sub for()
  dim_local a%
  for a%=1 to 10
     message "for :" + str$(a%)
     if a%= 5  then a% = 10
  next a%
  message "sortie for"
end_sub

sub while()
  dim_local a%
  while a% < 10
    a% = a% +1
    message "while :" + str$(a%)
    if a% = 2 then a% = 10
  end_while
  message "sortie while"
end_sub

Il suffit de régler la variable de sortie plus haute que la référence de la boucle.

Je viens de vérifier pour EXIT_FOR avec le programme suivant :

Code:

dim i%
for i% = 1 to 10
 if i% = 5 then exit_for
next i%
print i%

Le compilateur émet le code FreeBASIC suivant :

Code:

FOR V_I=1 TO 10
IF V_I=5 THEN
break;
END IF
NEXT V_I

Or l'instruction "break;" est une instruction du C ! Il faudrait la remplacer par l'instruction "EXIT FOR" du FreeBASIC.

Cela ne devrait pas être difficile à corriger !

Je n'ai pas testé les autres formes d'EXIT

Cool, ça ira encore plus vite à avancer

Salut tout le monde

@Jack

Voilà une année passée depuis la dernière version de travail du compilateur : Version 0.1 alpha 4 du 18 Mai 2014.
Y a-t-il du nouveau ?

Je développe actuellement un programme qui ne fonctionne que sur le compilateur et non sur l’interpréteur pour les deux raisons suivantes :
1) Le programme fait  beaucoup de calculs : la vitesse est donc appréciée avec le compilateur.
2) Et surtout parce que le programme utilise la récursivité qui marche très bien pour le compilateur (j’ai fais divers essais) et non pour l’interpréteur.

Je rencontre un bug ( ?) avec la fonction RND :

Code:

 print int(rnd(1)*500)

Ou

Code:

 print int(rnd(500))

Retourne TOUJOURS la valeur 449 pour le compilateur, tandis que pour l’interpréteur c’est aléatoire donc correct.

Le compilateur a subi, comme l'ensemble, un ralentissement dans son développement du fait que j'ai fait un séjour professionnel à l'étranger de plusieurs mois.

Son développement a néanmoins continué et je mettrai à disposition une nouvelle version d'ici quelques jours. Cette version sera même en avance sur le reste car elle contiendra les objets CONTAINER_TAB et TAB.

En voilà une bonne nouvelle,
il va falloir que je m' y mette au compilateur .

Merci Jack pour cette nouvelle nouvelle !
J’espère que le bug sur RND mentionné dans mon précédent message sera corrigé.

Super nouvelle, j'espère que dans les prochaines versions tu pourras aussi incorporer tes avancés sur les scene2d. Si la puissance des fonctions que tu ajoutes se combine avec la vitesse de la compilation, ce sera excellent

Bonne nouvelle ! Merci Jack.

Bon courage pour la suite...

Heu...Jack...
...aurais tu zappé d' ajouter les nouveaux objets au compilateur ?