MyLib va devenr un Interpreteur - Page 2

GoldenCrystal> Pourquoi au lieu de te moquer de geogeo tu ne lui expliques pas intelligemment où sont ses erreurs et comment les corriger pour faire avancer le schmilblick ?

Vertyos & Sasume

Sasume > Parce que ce n'est pas mon but... (Maintenant y'a des raisons à cela mais je les expliquerai pas ici, désolé si la réponse ne te convient pas)

lol je connais les motifs de ta 'non' réponse.

Dernier avertissement: continuez ailleurs.

Tiens, c'est gentil à vous les gars de pourrir le Topic.
Sinon j'ai repris le codage aujourd'hui, histoire de faire avancer le soft.

J'ai décidé de tokénéiser en commençant par la fin du fichier.
Vu que c'est du RPN et que le code doit être en sens inverse autant commencer par la fin.
Comme cela , je créer le fichier source au fur et à mésure.

C'est sure ça doit pas être commode comme façon de faire ( Le TIOS commence par le Début )
mais j'ai pas envie de me taper l'inversion du code ligne par ligne une fois la tokénéisation fini.

ça devrait bien avancer pour ce week-end, je sens que je vais attaquer la semaine prochaine les modification concernant l'interpreteur de MyLiB.

Pourquoi tu inverses ?
Pour obtenir une associativité à gauche des opérateurs arithmétiques ?

J'ai pas bien saisi la question.
C'est sur que vu que mon Parser RPN commence par la fin, on pourrait croire que cela en est la cause ; mais il n'en est rien du tout.

Disons qu'en regardant un source TI-Basic à l'hexaviewer , en mode RPN le début de code se trouve à la fin du fichier, et la fin au début. l'exécution se fait en remontant le fichier de la fin au début.
Vu que les fonctions de création de fichier TIGCC rajoute à la fin du fichier systématiquement,
je trouve normale de commencer à tokénéiser en commençant par la fin et en finissant au début.

J'aurai mon fichier tokénéisé dans le bons sens.

Je trouve ça assez curieux

Idem, de plus si je me souviens bien, les operandes ne sont pas dans le même sens selon les operateurs (entre + et < par exemple, on a une inversion). Je voulais essayer de réecrire un interpreteur de Ti-Basic pendant un moment, mais j'ai rapidement laissé tomber à cause de ce format trop tordu. (rien que commencer par la fin, je ne trouve pas ça spécialement naturel...)

Je vous signale que j'ai reécris le parser RPN, je n'utilise pas celui du TIOS.
En fait je n'utilise pas directement le RPN.
je me suis arrangé pour transcrire le RPN dans une forme très simple qui m'évite d'utiliser une pile supplémentaire.

voici comment je réduit l'expression :: z =( x==2 && !a || y<3+n )

D'abord je l'écris en RPN :: n 3 + y < a ! 2 x == && || z =
je rapelle que l'associativité est à gauche.
n 3 + correspond à 3 + n
n 3 + y < correspond à y < 3 + n

Et oui mon convertisseur RPN commence la conversion par la fin de l'expression.
j'ai vraiement la flemme de le refaire en commençant par le début .


Ensuite je réduit l'expression progressivement en exécutant les opérateurs ayant tous leurs arguments . # représente le résultat du calcul effectué : celui-ci se trouve sur le haut de la pile.
n 3 + y < a ! 2 x == && || z =
# + y < a ! 2 x == && || z =
# a ! 2 x == && || z =
# # 2 x == && || z =
# # # && || z =
# # || z =
# z =
# z =


finallement j'obtiens ceci :
# z = # # || # # && 2 x == a ! # y < n 3 +
l'interpretation se fait en commençant par la fin. chaque opérateur dépose son résultat sur le haut de la pile. # retire le résultat se trouvant se le haut de la pile pour s'en servir comme argument.

C'est sur ça prend plus d'espace mémoire que le RPN, mais je trouve que c'est un compromis acceptable. En effet c'est ainsi que j'ai programmé l'interpreteur dans 'MyLiB'.
Vu que j'ai pas envie de refaire un autre interpreteur, je me suis arrangé pour convertir le RPN dans cette syntaxe.

c'est pas très compliqué à écrire le convertisseur d'expression RPN.
C'est sure quand on n'en a jamais étudier les règles , ça aide d'avoir utilisé une Calc qui fonctionnait en RPN. Mais une fois qu'on a compris ce que signifie priorité des opérateurs, on peut facilement en écrire un. Voici les règles maison que j'ai pu tiré pour écrire mon convertisseur RPN (à quelques erreurs près car j'ai du encore le modifer ) :

Priorité décroissante par ligne

_______________________________
12 ) } ]
11 ! (-) ++ --
10 ^
9 * / %
8 + - &
7 < <= > >=
6 == !=
5 &&
4 ||
3 = ^= *= /= %= += -=
2 ,
1 ( { [
_______________________________

Attention : ++ et -- n'existe que pour la préincrémentation. ils sont implémenté en tant qu'opérateur unaire.

III- Notion de Pile
-------------------

Une pile n'est rien plus ni moins qu'une file d'attente.
Le premier élément déposé sur la pile se trouve à la fin de la pile.
Le dernier élément déposé sur la pile se trouve au début de la pile.
On dit que l'on dépose les éléments par le haut de la pile.
Ce genre de file d'attente est dite L.I.F.O. ( Last In First Out ).
Des règles régissent la façon dont les éléments sont retirés de la pile.


IV- Conversion en Expression RPN
--------------------------------


1- Pile d'expression RPN
------------------------

Ce n'est pas à proprement parlé une pile puisqu'il n'est aucunément
question de retrait d'élément de la pile. Nous nous contenterons de
déposés des constantes littérales/symboliques et des opérateurs sur
le haut de la pile pour constituer une expression RPN.

2- Pile d'opérateurs
--------------------

Elle servira à entasser les opérateurs d'une expression algébrique.
Les opérateurs entassés sur cette pile seront retirés selon leur niveau
de priorité dans le language pour être déposé sur la pile RPN.

a- Règles générales
-------------------

** Tout opérateur dépose sur la pile d'expression RPN la constante litérale
ou symbolique qui la précède
** Tout opérateur retire de la pile tous les opérateurs de priorité supérieur
ou égale
** Tout opérateur de niveau > 2 est déposer sur la pile
** Le début de ligne retire tous les opérateurs restant de la pile
** Tout opérateur rétiré de la pile est déposé sur la pile d'expression RPN

b- Particularité des opérateurs paires : () []
----------------------------------------------

** le symbole fermant est l'opérateur de plus haute priorité
** le symbole fermant ne peut être retirer que par le symbole ouvrant équivalent
** Le symbole fermant des fonctions/tableaux doit être déposé sur la pile RPN
** le symbole ouvrant des fonctions/tableaux doit être déposé sur la pile RPN
après que soit déposé la constante désignant le nom de la fonction/tableau
** le symbole ouvrant agit comme l'opérateur de plus basse priorité
** les symboles ouvrant/fermant de simple parenthèse ne sont pas déposé sur la
pile RPN

Finallement, je vais revenir sur le principe de recherche des arguments manquant sur le haut de l'estack.

Ce qui me permet de réduire la taille de mon expression :

Expression algébrique
-------------------------
z =( x==2 && !a || y<3+n )

Expression RPN
-----------------
n 3 + y < a ! 2 x == && || z =

Expression MyLiB
-------------------
z = || && 2 x == a ! y < n 3 +

finallement c'est comme du RPN mais à l'envers.

l'interpretation , comme vous vous en seriez douté donne :
n 3 +
# y <
a !
2 x ==
# # &&
# # ||
# z =

Bon finallement je tiens le bon bout. Impécable, aucun Tag supplémentaire par rapport au RPN de TI

-> Vertyos && Sasume :

Excusez moi du retard dans la réponse .Je me trompe peut-être mais voici ce que j'ai compris :

l'inversion s'explique par :
l'exécution d'une expression RPN, expemple ci-dessus commence par la gauche alors que le parcours de la Pile par les fonctions du TIOS se fait de la droite vers la gauche. je me suis donc arrangé à tout faire dans le même sens,c'est à dire en remontant l'ESTACK à partir du Sommet.
En fait, je ne veux pas gerer une pile spécifique où mettre en attente les arguments.
J'ordonne l'expression RPN de sorte qu'un opérateur n'ai pas plus de 2 arguments ( opérateur binaire ou unaire).

le fait de mettre le RPN dans le sens du parcours de la pile par les fonctions du TIOS m'évite la gestion d'une pile d'arguments retardés, puisque l'opérateur rencontré dans une expression retire les arguments le précédent ( et en cas d'omission d'argumentsl'opérateur les retires dans la pile des résultats temporaires ).

______________________________________________________________________________________________

Si je tokénéise en commençant par le bas du fichier, j'obtiens directement mon fichier exécutable dans le bon sens, vu que la 1ere ligne est en fait la derniere et que je commence le parcour de la pile en commençant pas le bas

Hmm excuse moi, mais j'ai pas bien compris ton truc
Tu fais une pile de résultats temporaires et tu veux pas faire de pile d'arguments ?
D'une part, pile de résultats et pile d'argument sont la même chose dans un interpréteur bien construit, et d'autre part tu risques de créer beaucoup plus de problèmes que tu n'en résoud avec ça ^^
Exemple tout bête:
Tu as une fonction A(Argument1, Argument2, Argument3)
Mettons que tu fasse cet appel: A(1, 3 + x, 4) (x étant une variable)
Tu vas faire comment pour te débrouiller avec le 3 + x hmm ?
Si on est dans ta logique on aurait en prefix A 1 + 3 x 4 A va donc chercher ses arguments lui même...
Il prend le premier, c'est un nombre tout va bien...
Il prend le deuxième, c'est une somme.... Cela veut-il dire que A doît calculer lui-même ses arguments ? Une manière simple de corriger ce problème serait d'appeler l'interpréteur de manière récursive mais alors comment lui dis tu où il doit s'arrêter dans le parsing de l'expression ? Pas de problème, ça peut se faire en lui donnant un argument qui dit de n'interpréter que le prochain token et de mettre son résultat sur la pile des résultats. Ok tout va bien jusque là, mais si ton expression est très complexe, cela veut donc dire que tu auras un nombre très grand d'appels impriqués, donc un très grand usage de la pile et par conséquent un risque de stack overflow...
Du coup, premièrement ta pile de résultat n'est pas très utile vu que tu n'as besoin que d'un résultat a la fois, et deuxièmement, tu dois faire de multiples appels de fonctions, coûteux autant en mémoire qu'en vitesse d'éxécution.

On te donne une manière qui fait partie des plus simples pour interpréter un programme, a savoir l'utilisation d'une pile d'arguments, qui a l'inverse de la méthode récursive ne débordera que rarement (et dans ce cas là même tu pourras arrêter toi-même l'interprétation en cours sans planter la calcularice...) Alors pourquoi chercher a faire un truc plus compliqué ?

Surement que j'ai du mal m'exprimer; ça m'arrive souvent ces temps ci.
------------------------------------------------------------------------
Le Parser de Texte Commence l'analyse par la fin de l'expression.
---------------------------------------------------------------------------
Quand je parle de pile de résultats temporaire , il s'agit en fait de la pile d'arguments ( Estack TI ) . J'ai toujours procédé ainsi dans MyLiB et il n'y pas de raison de changer cela, vu que je ne vais pas faire un autre interpreteur.

Le code d'un programme est tokénéisé dans une variable comme un programme TI-Basic.
Les seuls choses copiées sur l'Estack sont les résultats temporaires des calculs qui servent à la fois d'arguments aux fonctions.

Je fait exactement comme le TIOS pour ce qui concerne l'appel à une fonction ou un sous-programme. La seul différence c'est le fait que j'inverse le RPN.

A( 1, 3 + x, 4) donne
END_TAG 4 x 3 + 1 A USERFUNC_TAG

Si tu veux je peux mettre un Lien vers le parser pour que tu puisse voir ce que ça donne sur TI

T'as déjà un truc qui marche, pour tester la vitesse ?

Ouh, je n'en suis pas encore à ça. De plus je ne fait que parler du Parser de Texte.
Je n'ai pas encore retoucher à l'interpreteur de MyLiB.

Là je finis complètement la tokénéisation et l'écriture des offset de JUMP.
je fait actuellemnt la pile de gestion des saut pour les structures de contrôle et les sous-programmes.
Ensuite je doit modifier un peu l'interpreteur pour avoir exactement le même format de fichier tokénéisé. Normallement y a que les fin de ligne à modifier dans l'interpreteur.
Mais là j'ai un peu arrêté de travailler dessus.