compilateur version de travail 0.1 alpha 3

Une nouvelle version de travail du compilateur est disponible sur mon WebDav.

COMPILATEUR V 0.1 alpha 3, version du 6 mai 2014, basée sur PANORAMIC V 0.9.25

A - Améliorations

- correction du bug sur FRAC
- correction du bug sur MID$
- correction du bug sur DLL_ON
- correction d'un bug sur l'affectation d'une variable
- codage de DATA, READ, RESTORE
- codage de SUB avec paramètres
- codage de END_SUB
- codage de DIM pour les tableaux à 2 indices (DIM est donc totalement utilisable)
- codage de DIM_LOCAL

B - Contraintes (provisoires: elles seront levées ultérieurement) :

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 - Redéfinition d'une texture à un objet 3D
Redéfinir une nouvelle texture à un objet 3D qui en possédait déjà une provoque un plantage.
Je mets de côté cette correction pour l'instant.

C.7 - 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.8 - 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_FIND_CLOSE
FILE_NAMES_ADD

C.9 - Ce qui va changer pour les fichiers binaires :
FILEBIN_READ : sera remplacé par une fonction V=FILEBIN_READ()
FILEBIN_HEXA_READ : sera remplacé par une fonction V=FILEBIN_HEXA_READ()
FILEBIN_BLOCK_READ : sera remplacé par une fonction V=FILEBIN_BLOCK_READ()
FILEBIN_BLOCK_WRITE : sera remplacé par une fonction V=FILEBIN_BLOCK_WRITE()

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

C.11 - Une erreur de débordement de tableau n'est pas signalée.

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

Rudement intéressant, merci Jack !
Pas le temps de tester ces jours-ci (absence), mais je ne doute pas que beaucoup vont se jeter dessus !

Super nouvelle, content de voir que ça avance bien.
Je pense que dans les prochaine version de l'éditeur permettra de vérifier que le code généré est compatible avec le compilateur avant compilation (vérification des règles que tu viens d'indiquer ci dessus ?)

Merci Jack
ou trouve tu cette energie?

Merci Jack.

minderstorm a écrit:

Merci Jack
ou trouve tu cette energie?

Sans doute, dans sa jeunesse !   

Toutes mes félicitations, Jack, pour l'énorme travail que tu fournis.

Une petite question. Je m'étonne de ceci:

Citation :

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

Jusqu'à maintenant, tu nous avais habitué à une compatibilité ascendante sans faille. Alors que je peux comprendre la transformations des commandes de lecture de fichiers en fonction, je reste perplexe devant l'affirmation "Ce qui ne sera pas implémenté:". Est-ce que ça signifie "pas du tout" ou "pas dans l'immédiat" ? Si c'est "pas du tout", est-ce que cela provoquera une erreur ou sera simplement ignoré, voir retournera une valeur fixe (0 par exemple) pour les fonctions ? Parceque - pardon - beaucoup de programmes (les miensn en tout cas), utilisent intensivement VARIABLE(), LABEL(), ADR() et FREE. J'avoue que là, tu m'inquiètes.

J’ai fais quelques tests avec cette nouvelle version.
Je constate que le problème sur DLL n’est pas corrigé pour autant.
Certes, il n’y a plus d’erreur à la compiltion et on obtient un .exe.
Seulement, si on veut exécuter cet exe on a droit à xxx.exe a cessé de fonctionner.

J’ai testé plusieurs codes utilisant DLL :  compilation ==== >  OK ;  exécution ==== > le programme a cessé de fonctionner.

Voici un code minimal

Code:

dll_on "kernel32.dll"
dll_off
message "terminé"

J’enregistre  ce code sous test.bas.
Je le compile :  c’est OK et j’obtiens test.exe.
Je lance test.exe, et voici ce que j’obtiens :





Un grand BRAVO pour l'amélioration du comportement de la commande INPUT.
Sous l'interpréteur, elle n'est pas confortable à utiliser; par contre, sous le compilateur, elle aura sa place : c'est bien pratique!

Pour ceux qui veulent la tester :

Code:

dim n$
input "votre nom ?";n$
message "Bonjour " + n$

Il vaut peut-être mieux que INPUT ne laisse pas de trace sur le FORM, mais ça peut se discuter.

Bravo Jack !

Je vais télécharger cette version tout de suite !

En faisant des tests, je me suis rendu compte que par erreur, j'avais mis sur le WebDav une version dans laquelle la 3D était inactivée.
Je viens d'y mettre la version complète, elle porte le même nom et le même indice que la version déposée hier.

Le problème de DLL persiste.

Merci Jack pour cette nouvelle version !

Je l'ai testée avec mon programme de biomorphe. Il marche très bien.

Le langage cible est toujours le FreeBASIC. Est-ce le choix définitif ?

Je me permets de renouveler mes demandes pour avoir des options permettant :

- de dissocier la DLL panoramic.dll du programme exécutable afin de rendre celui-ci plus court
- de consulter (et donc modifier) le code FreeBASIC généré
- d'installer FreeBASIC une fois pour toutes

Et aussi avoir le choix entre « Compilation tout court : exécution en mémoire sans générer un exe (utile pour les tests) » et «compilation avec exécution » (création de .exe).

papydall a écrit:

Et aussi avoir le choix entre « Compilation tout court : exécution en mémoire sans générer un exe (utile pour les tests) » et «compilation avec exécution » (création de .exe).

Là ce sera sans doute plus difficile car pour le moment c'est FreeBASIC le compilateur et celui-ci crée toujours un exe.

La compilation en mémoire serait possible en utilisant TCC comme compilateur après traduction du code Panoramic en C.

Jack a laissé entendre qu'il avait fait des essais avec le C et le Pascal comme langages cibles mais il n'a pas donné de détails.

Intéressant, Jean-Debord ! Pascal comme cible ? Avec FreePascal (come celui utilisé dans Lazarus), on a une portabilité très large (windows, mais aussi toute la gamme des Unix, Linux, Ubunto etc, ainsi que Android). Et le lien vers les DLLs en Delphi (converties en Pascal) serait évident...

Sous FBIde, dans le menu Exécuter il y a les sous-menus
Compiler
Compiler et Exécuter
Exécuter
Exécution Accelerée
Etc…

Il y a même un bouton Exécution Rapide.

J’ai déjà demandé :

Citation :

Autre chose, on ne souhaite pas toujours créer un exécutable sur disque mais une simple exécution en mémoire (surtout en phase d’essai d’un bout de code ou d’un test quelconque). Alors, si on dispose d’un choix (options ou icones)  COMPILE  ou COMPILE & RUN  ou MAKE ou BUILD ou que sais-je encore ?

Et

Jack a écrit:

L'idée d'une option donnant le choix entre "compilation" et "compilation avec exécution" me plait bien.

Alors si c’est possible, pourquoi pas ?!

papydall a écrit:

Sous FBIde, dans le menu Exécuter il y a les sous-menus
Compiler
Compiler et Exécuter
Exécuter
Exécution Accelerée
Etc…

Il y a même un bouton Exécution Rapide.

Oui mais même dans ce cas il y a création sur le disque d'un exécutable FBIDETEMP.exe qui est effacé lorsqu'on quitte FBIde.

Je pensais à une compilation 100% en mémoire, sans rien écrire sur le disque.

C'est faisable avec TCC (voir mon article) : le programme est écrit dans une variable chaîne de caractères et la compilation se fait entièrement en mémoire.

QuickBasic avait une option pour faire cela.

Perso, c'est sûr, je serais pour mais je n'ai pas la moindre idée de la complexité du changement de langage et du système de compilation.
Faites au mieux pourvu que ce soit le plus compatible et le plus rapide possible.

Il est évident que Jack est souverain dans le choix de son langage cible pour le compilateur. FreeBasic est peut-être une cible plus "aisée" à partir d'un langage Basic. Je pense que Jack a passé de multiples possibiltés en revue, avant de se fixer sur ce choix.

Pour ma part, j'aurais préféré FreePascal. Sources pratiquement compatibles avec Delphi, mais portable sur pleins de systèmes: toute la gamme Windows, avec mode 64 bits natif, toute la gamme des clônes Unix, Andoid et d'autres. Avec la possibilité de cross-compiler sur un système A pour un système B... Mais la conversion d'un source Basic en Pascal n'est sûrement pas facile.

Il ne devrait pas être très difficile de faire un traducteur du langage Panoramic dans un langage cible donné. D'ailleurs Jack a laissé entendre qu'il l'avait déjà fait pour le C et le Pascal.

Les fonctions qui gèrent les objets graphiques sont traduites par des appels à la DLL panoramic.dll ; les autres instructions de Panoramic sont assez classiques et ont leurs équivalents dans les autres langages.

FreeBasic et TCC ont des versions pour Linux et même pour d'autres processeurs tels que les ARM. En revanche le "traducteur" de Panoramic vers le langage cible, ainsi que la bibliothèque panoramic.dll, ne sont à ma connaissance disponibles que pour Windows.