Rah purée les parenthèses aussi ça marche



J'ai juste un problème avec les hexa bizarement, faut que je regarde, mais c'est sûrement trois fois rien.

Par contre, la symbole % est pas bindé sur le clavier ? Au pire, je vais remplacer quelque chose, mais faudrait prévoir ça. ^^

Pedrom aussi.

Hein t'as vu ça, il me faut que deux lignes pour récupérer ce que je passe en ligne de commande.

A moi aussi, depuis peu :] Mais tu économises 2 parenthèses et 2 guillemets !

(en fait j'ai l'impression d'être hors sujet... pourquoi Sasume parlait-il de ça? Tu n'es pas en train de faire une assembleur Folco?)

23 messages sont trop pour que je regarde ce qu'il faut que je dise. Folco, c'est bon ?

PpHd (./122) :
23 messages sont trop pour que je regarde ce qu'il faut que je dise. Folco, c'est bon ?

OUI

Thibaut (./113, ./114, ./115), ce que tu faisais, c'est exactement le genre de bidouilles qu'il faut faire pour gérer ce genre d'expressions avec du parsage LL. C'est une bidouille parce que ça ne correspond pas du tout à l'arbre de parsage naturel (tu construis un arbre différent de l'arbre de parsage) et comme tu dis c'est extrèmement compliqué.

S'il est différent mais correct, je m'en contenterai. J'ai jamais rien compris à la formalisation mathématique des grammaires, alors j'avais pris une pile de feuilles et une après midi pour touver un algo qui semblait marcher tant pis si c'est pas le plus beau.

C'est le mieux qu'on puisse faire avec du LL(1) de toute façon. Donc tu pourras te vanter d'avoir retrouvé tout seul la solution connue au problème de la récurrence à gauche du parsage LL(1) sans même savoir ce que c'est.

PpHd, voilà les messages clés de Kevin qui posent la problématique. Mon parseur marche, et le tien marche de la même manière. Et ceci, pour Kevin, n'est pas conforme :

Kevin Kofler (./99) :
C'est le problème avec le parsage LL(1), les opérations "associatives à gauche" (le plus courant) posent problème.

Kevin Kofler (./101) :
Normalement, + et - doivent avoir la même priorité!

Donc tu as 2 opérations de la même priorité:
x OP y OP z
On dit que l'opération ou la famille d'opérations (genre + et -) OP est associative à gauche si:
x OP y OP z = (x OP y) OP z
On dit que l'opération ou la famille d'opérations (genre + et -) OP est associative à droite si:
x OP y OP z = x OP (y OP z)
L'associativité à gauche ou à droite est une question de conventions, pas une propriété intrinsèque de l'opération, mais la convention courante est que {+,-} est associatif à gauche.

On dit que l'opération ou la famille d'opérations (genre + et -) OP est associative si:
(x OP y) OP z = x OP (y OP z)
(Là, c'est une propriété intrinsèque de l'opération.) On peut donc noter:
(x OP y) OP z = x OP (y OP z) = x OP y OP z
et par conséquent l'opération sera à la fois associative à gauche et associative à droite.

+ est associatif, mais - ne l'est pas, donc la famille {+,-} non plus! Donc si tu parses de manière associative à droite, le résultat ne correspondra pas aux conventions (associativité à gauche).

Le problème, c'est que si tu parses top-down de gauche à droite (LL), tu construis toujours des arbres associatifs à droite. Les arbres associatifs à gauche demandent une récursion (un appel récurrent) à gauche et ce n'est pas possible en parsage LL (tu tombes en une récurrence infinie). Il existe différentes bidouilles pour corriger ça, mais la méthode la plus propre est de parser en LR (bottom-up de gauche à droite). Mais pour ça, il faut construire une table, tu ne peux pas le faire avec un parseur écrit directement à la main.

Kevin Kofler (./103) :
3-2+1 = (3-2)+1. L'algorithme de Martial donne 3-(2+1), ce qui est totalement faux.

Kevin Kofler (./107) :
Thibaut, c'était du parsage par découpage, peut-être, ton truc? (C'est essentiellement du bottom-up, ça, et c'est la manière de laquelle je codais intuitivement le parsage avant d'avoir appris le parsing.) Ce que j'appelle "parsage par découpage", c'est: on veut découper "x+y-z", donc on recherche + et -, en partant de la droite parce que c'est associatif à gauche. Donc on coupe en "x+y" et "z". Le problème, c'est que ça coupe les chaînes en 2 à chaque découpage, donc soit tu copies, soit tu détruis l'original en remplaçant l'opération par des \0. Et tu traverses les chaînes plusieurs fois aussi, donc l'efficacité n'est pas top. Et en plus, tu dois bidouiller quand il y a autre chose que des opérateurs, genre des parenthèses, sinon tu feras des bêtises là aussi.

Cela dit, ce que fait Folco m'a l'air de ressembler à ça, donc dans ce cas c'est facile de corriger la priorité. (Il faut rechercher à partir de la droite quand on découpe pour un opérateur associatif à gauche.)

Qu'en penses-tu ? Notre manière de faire est fondamentalement fausse et il faut corriger ?

Je n'aurais qu'une question. Est-ce que 3-2+1 donne 0 ou 2 ?

Ben nos algos donnent 2.

Kevin dit que ça fait 0.

Qui a raison ? C'est pas moi le mathématicien dans l'histoire les gars, à vous de voir.

Par convention, 3-2+1 = (3-2)+1 = 1+1 = 2.

Ton procédé du ./97 décompose d'abord incorrectement en Eval(3, -, *( 2 + 1 )). Mais apparemment ton ComparePriorité résout le problème.

Kevin Kofler (./126) :
Donc tu pourras te vanter d'avoir retrouvé tout seul la solution connue au problème de la récurrence à gauche du parsage LL(1) sans même savoir ce que c'est.

Martial aussi sans doute !
D'ailleurs, tu as essayé le parenthesage à droite Martial ? Sur ta copie d'écran, les priorités sont toutes forcées à gauche. Ca roule aussi avec des calculs du genre 100+(3-1*4)*10 ?

Oui.
Pas ton exemple précisément, parce que 3-1*4 est négatif. Si je fais avec 5-1*4, oui.
C'est dû au fait que je fais pas encore de vraies opérations sur 32 bits pour les multiplications et divisions. Mais l'algo est bon.

Brunni (./121) :
(en fait j'ai l'impression d'être hors sujet... pourquoi Sasume parlait-il de ça? Tu n'es pas en train de faire une assembleur Folco?)

Là je suis sur l'évaluateur d'expression de mon assembleur. Mais t'inquiète pas, tout ça ne tombe pas dans l'oreille d'un sourd.

il va être top mooomoot ton assembleur si il supporte ce genre de truc plus un linker

Il faudrait déjà qu'il sorte.
Mais là je suis décidé, je cherche pas à faire un proof ou à tester je ne sais quelle techno. Je ne peux prédire de rien, mais mon but est d'y arriver.

<salife>
En réalité, je n'ai pas fini d'écrire la gestion de la ligne de commande... mais ça fait déjà beaucoup de choses, vu qu'une partie du linker est écrite, la plus grande partie de la table des opcodes, la gestion des symboles (création des symboles, relogés ou non, accès à leur valeur), les labels, l'ouverture des fichiers, la mise en cache et encore d'autre trucs pas essentiels, mais qui serviront partout et qui ne sont plus à faire.

La ligne de commande supportant "define truc=chose", je suis bien obligé de lire le symbole truc, de l'enregistrer, de vérifier son unicité, et d'évaluer l'expression chose.

En fait je me demandais, à quoi ça sert un linker pour du code ASM? En fait que réalise le linker et que réalise l'assembleur dans ton cas Folco?

L'assembleur produit du code objet. C'est à dire tout ce qui peut être assemblé d'entrée de jeu (move.l d0,d1 par exemple).
Le liner va s'occuper de tous les sauts. Quand tu as un saut, tu connais pas encore l'endroit où tu sautes, donc tu peux pas le coder. Tu mets ça dans un table de saut à résoudre après assemblage.

C'est nécessaire parce mon assembleur étant multi-source, il est impossible de savoir où seront, dans le binaire final, les binaires correpondant aux autres fichiers sources.
Et ça, c'est le boulot du linker : rassembler les binaires de chaque source, en créer un unique avec un stub éventul, et résoudre les sauts et adressages entre tout ça.

Ordinairement, quels sont les opérateurs les plus prioritaites dans une expression ?
Les décalages >> et << ou les opérations logiques & et | ?

Folco (./134) :
En réalité, je n'ai pas fini d'écrire la gestion de la ligne de commande... mais ça fait déjà beaucoup de choses, vu qu'une partie du linker est écrite, la plus grande partie de la table des opcodes, la gestion des symboles (création des symboles, relogés ou non, accès à leur valeur), les labels, l'ouverture des fichiers, la mise en cache et encore d'autre trucs pas essentiels, mais qui serviront partout et qui ne sont plus à faire.

Juste au hasard, tu as testé toutes ces fonctionnalités ?

Oui, sauf la mise en cache. Pour ce qui est des symboles, je finirai de tester quand j'aurai fini ce que je fais (ajout d'un symbole avec une valeur, avec un relogement, accès aux données d'un symbole).

Cool, en pourcentage d’avancement (sur le projet dans sa totalité), tu pourrais donner un chiffre ?

Putain, t'as des questions qui tuent toi, je revenais pour te le dire, on voit la confiance

Sincèrement, je sais pas trop évaluer ça. Le linker est pas fait, mais vu mes fichiers objet ça devrait pas être trop galère (ya beaucoup de choses de machées).
Je dirais 20%, peut-être que je m'avance. Je sais pas trop estimer.

Tout ce qui est parsing de la ligne de commande, fichier de conf et ouverture des sources, création des données nécessaires à l'assemblage de chacune est fait et testé. Ca a fait avancer pas mal de domaines connexes, surtout au niveau du parsing, j'ai déjà quelques fonctions puissantes pour la suite.

Folco (./137) :
Ordinairement, quels sont les opérateurs les plus prioritaites dans une expression ?
Les décalages >> et << ou les opérations logiques & et | ?

Habituellement les >> et << sont prioritaires sur les opérateurs logiques, mais passent après les opérateurs mathématiques communs. Tu peux regarder la table "Priorité des opérateurs" en bas de cette page à titre d'information : c'est celle du langage C.

./136> Okay merci alors ce que je te disais c'était pas du ressort de l'assembleur mais du linker du coup

Oui.

Merci Zephyr. J'étais loin d'imaginer que ces opérateurs étaient si peu prioritaires, j'aurais vraiment pensé l'inverse oO

C'est vraiment bizarre effectivement, mais ça arrange bien le C++ parce qu'on peut faire du std::cout << 2+3; sans avoir besoin de parenthèses.

ce vieux hack...

où as-tu vu un hack ?

Le fait de surcharger les opérateurs de décalage de bits pour signifier l'entrée-sortie.

De tte rien ne vaut printf