Evaluation d'une expression - Page 2

Folco (./28) :
Marrant que ce soit un relogement. Pourquoi ne pas en faire un entier à réévaluer après le linking ? Une fois que l'on connait la position de chaque label ?

C'est exactement ce qui se passe. C'est un relogement résolu en temps de linking. Mais ce qui dit au linker quoi calculer, ça s'appelle un relogement (et c'est représenté comme un "vrai" relogement, à un ou deux flags près).

Folco (./30) :
nop, c'est juste une entrée avec le flag kivabien dans la table d'adressages à résoudre

Une "entrée dans la table d'adressages", c'est un relogement.

Folco : J'avais pas en tête que tu éditais les liens en parallèle de l'assemblage. Ça change tout

Mais TIGCC ne fonctionne pas comme ça, donc dans TIGCC, l'assembleur doit communiquer les informations au linker à travers le fichier objet. Donc on ne peut pas mettre n'importe quoi, si je veux rajouter une fonctionnalité, je dois étendre le format objet.

Kevin Kofler (./31) :
Une "entrée dans la table d'adressages", c'est un relogement.

Ah ok, question de vocabulaire alors. Je pensais au format de relogement tel qu'on le trouve dans un binaire. En fait, et suite à la discussion sur le linking qu'on a eue sur IRC, je devrais tout reloger. Puis ta méthode de relaxation m'a l'air de poutrer puisamment.


Pour l'extension du format objet, le mien ne permet pas plus que TIGCC. Comme je ne veux pas l'étendre pour des questions de mémoire et de performance, je n'ai d'autre choix que de renvoyer le linker vers le source au moyen d'un pointeur vers l'expression à calculer. C'est crade, mais je n'ai pas les moyens de me payer un format objet du style de celui de TIGCC.

Pour faire plus propre, tu ne voudrais pas stocker l'expression sous forme intermédiaire (arbre ou pile) ?

Je stock un pointeur vers cette expression : rapidité d'écriture dans la table, taille constante qui permet de parcourir très vite la table, taille très réduite, limitation de la longueur des symboles et des lignes inutile etc... Que du bon.

L'emmerdement que je rencontre, c'est de pas arriver à trouver de solution pour ne créer qu'une table de symboles si plusieurs fichiers importent le même header (typiqyement tios.h qui est gros, et qui prendrait (10*nombre de symboles) octets.

De toute façon chaque fichier source est assemblé séparément puis rassemblés par le linker, non ?

Quand tu parses un fichier qui importe tios.h, tu dois effectivement construire la table des symboles correspondant, puis à la fin de l’assemblage tu la détruit, non ?
Sinon tu peux faire comme GTC : utiliser quelques headers précompilés. Quand tu rencontres un .h tu le parses et en construis une représentation abstraite que tu stocke et réutiliseras à chaque prochaine compilation.

Pas bête ce que tu dis, j'y reviens bientôt. A ceci près que il n'y a pas de .h spécifique on-calc... Et de toute manière, include se comporte de la même manière pour un header ou un source, il n'y a pas de vraie différence entre les deux si on regarde bien : l'assembleur agit de la même manière. Utiliser la distinction asm/h est déjà une barrière d'abstraction que l'on se pose, ça ne correspond pas à une réalité.

Bien sûr, mais tu peux décider de te comporter différemment selon l’extension du fichier (enfin, si son nom se termine par _h par exemple). Je pense en tout cas qu’un header précompilé pour tios.h ferait gagner un temps fou. Enfin, faudrait mesurer en fait. Si l’assembleur est largement utilisable sans ces astuces, autant garder un fonctionnement simple…

A la base, j'avais pensé à une table des fichiers inclus, que chaque fichier regarde avant d'inclure un autre fichier :
- le code exécutable est recompilé dans le fichier qui l'inclut
- la table des symboles et des macros est liée à la table du fichier qui inclut le-dit source. Ca évite de recalculer une valeur dès qu'on tombe sur un symbole.

Mais pour le moment, je code au plus simple malgré mes specs, pour espérer sortir quelque chose. Qui plus est, j'ai déjà implémenté un système de swap qui balance en archive tous les handles utilisés par le programme si on manque de mémoire. Mais ton idée de supprimer des fichiers (symboles et macros par exemple) est bonne. Ceci dit, on ne peut pas virer ce qui sert au linker évidemment (relogemenrs, exports)

Folco (./39) :
Et de toute manière, include se comporte de la même manière pour un header ou un source, il n'y a pas de vraie différence entre les deux si on regarde bien : l'assembleur agit de la même manière. Utiliser la distinction asm/h est déjà une barrière d'abstraction que l'on se pose, ça ne correspond pas à une réalité.

Euh si, normalement il y a une différence: un .asm ou .s est compilé séparément, un .h est inclus dans un autre! Certes, il y a des porcs(*) qui utilisent include avec des .asm, mais c'est un hack totalement obsolète, on a des linkers pour ça maintenant!

(*) dans le sens de "personnes aimant les techniques de programmation sales"

On est bien d'accord, mais ça ne constitue qu'une abstaction que l'on se fixe, dans le but de programmer proprement. L'assembleur n'y voit que du feu.
A moins qu'il y a une différence qui m'ait échappée ? Mais un "include truc.asm" ou "include truc.h" produira exactement le même code, à contenu identique.

J'avais pensé, à un moment, différencier les types fortement, en ne permettant dans les headers que les définitions de symboles et de macros, et en ne permettant l'assembleur que dans les sources. Mais ça fait perdre en compatibilité (essaye de compiler un programme de Flanker avec ça )

Folco (./43) :
On est bien d'accord, mais ça ne constitue qu'une abstaction que l'on se fixe, dans le but de programmer proprement. L'assembleur n'y voit que du feu.

Bah non justement, pas si tu utilises les .asm correctement!

A moins qu'il y a une différence qui m'ait échappée ? Mais un "include truc.asm" ou "include truc.h" produira exactement le même code, à contenu identique.

C'est bien pour ça que include "truc.asm" est une cochonnerie!

La compilation séparée, c'est:
1. L'assembleur assemble toto.asm. Il ne voit même pas truc.asm! Il produit toto.o.
2. L'assembleur assemble truc.asm. Il ne voit même pas toto.asm! Il produit truc.o.
3. Le linker lit toto.o, truc.o et tigcc.a et produit un exécutable.

essaye de compiler un programme de Flanker avec ça

Je n'y peux rien s'il programme comme un porc.

Oui nan mais je sais bien, je pense comme toi, mais tu ne reconnaitras pas que je n'ai pas tort, même si on est d'accord sur la propreté de programmation.

De toute façon sur TI tous les fichiers seront des fichiers TEXT.

Ouep. Mais rien n'empêche de définir un autre format.

Bon, pour revenir à mes symboles, je tombe sur un truc fun. Dans ma table de symboles, j'ai donc des définitions de ce genre :

<ABCD>			<checksum>	<flag entier>		<valeur sur 32 bits>
<tios::HeapFree>	<checksum>	<flag _ROM_CALL_>	<numéro du romcall>

Ca, c'est si je tombe sur un
jsr tios::HeapFree

Par contre, si je tombe sur un jsr _ROM_CALL_ABC, j'aurai
<_ROM_CALL_ABC> <checksum> <flag _ROM_CALL_> <ABC>
Marrant, c'est un cas où un symbole se définit par lui-même. Bref, c'est fun, mais ça se fait tout seul.

Bon, je vais en fait refaire une estack. C'est peut-être pas beau et lourd, j'en sais rien, mais ... je suis pas bon.

Voilà comment ça va être organisé, sur la pile :

Caractères à traiter

#
012345679abcdefABCDEF
%$

+-/*
()
~
<< >>
& |

----------------------------------

Priorités

~
()
<< >>
*/
+-

----------------------------------

EStack

0000	END_STACK
0001	32 bits integer, next there is a 32 bits integer
0002	+
0003	-
0004	*
0005	/
0006	(
0007	)
0008	<<
0009	>>
000A	~
000B	|
000C	&
000D	espace vidé, à ignorer.

----------------------------------

Séparateurs

VIRGULE,SPACE,EOL,EOF,TAB

Un truc me turlupine. Comment différencier proprement :
TRUC(a0), qui est un pointeur vers a0+truc
et
TRUC(a0), qui est le produit de truc par la valeur numérique du symbole a0 ?

Oublié de préciser : une expression peut aussi être _ROM_CALL_xyz ou _RAM_CALL_xyz. MAis pour ça, je sais comment je vais faire je crois.

(en fait, je me rends compte que je vais faire quelque chose qui ressemblait à ce que m'a proposé sasume, non ? Au moins dans la décomposition de mon expression.)

Voilà, j'ai écrit ça. C'est pas encore testé, j'ai plusieurs fonctions à écrire derrière : Fichier joint : parse.txt
Surtout, si vous pensez que je vais dans le mur, dites-le tout de suite. J'ai juste besoin de savoir si vous pensez qu'à partir de ce parsing, je pourrai arriver à évaluer mon expression.

ps : je ne considère pas le fait que ma méthode ne soit certainement pas la meilleure soit aller dans le mur.

Aïe, de l'ASM Ce n'est pas facile de suivre l'algo qui se cache derrière, mais ça dégage toujours une certaine élégance visuelle.
Tu n'as pas fait un algo sur papier que tu pourrais scanner pour montrer ici ?

Euh...

En fait, je contruis une pile d'expression sur la pile. Le code n'est en fait pas le plus important. L'important, c'est de savoir si à partir de la pile d'expression que j'ai écrite, je vais arriver à déterminer un entier 32 bits à la sortie.
Dans la pile, je devrais donc trouver quelque chose dans ce genre là :
[ Parenthèse ouvrante] [ entier ] [ addition ] [entier ] [ parenthèse fermante ] [ addition ] [ entier ] [ fin de pile ]

Je sais pas si c'est bien, si j'ai assez d'éléments pour calculer.

Thibaut (./51) :
mais ça dégage toujours une certaine élégance visuelle

Y'aurait pas ma femme, j'aurais du code encadré dans le salon

(un truc class, c'est la rosace (en relief) de cartes perforées gros système)

Martial, tu peux regarder ce que j'ai fait dans PedroM/MAYLIB aussi (parser.c).

Je ne suis pas sur que les parenthèses doivent figurer dans la pile. Avec réserves, je crois que la pile est un arbre syntaxique dans lequel les liens sont implicites, à la différence d'un "vrai" arbre où les arcs sont des pointeurs. Les parenthèses disparaissent lors de la construction de l'arbre. Ne te décourage pas si je t'embrouille et que c'est à raison : la traduction de grammaires est un domaine plutôt fascinant (mais sans doute moins quand on se tape les algos en ASM).

l'idéal c'est d'arriver à transformer une expression 1 * ( 2 + 3 ) en RPN

2
3
PLUS
1
FOIS

c'est cette etape qui est chiante.


ensuite tu fais
tant que pile a plus de 1 élément:
pop A
pop B
pop operation
push (A operation B)

a adapter pour les operations unaires. Le but est de detecter le "plus" et de faire cette operation avec les 2 entrées precedentes. Comme ça si t'as un "moins unaire" ça suffit de faire l'operation avec l'entree precedente.

(ben ce que j’avais proposé correspondait justement à la solution de ce problème)

Folco (./49) :
Un truc me turlupine. Comment différencier proprement :
TRUC(a0), qui est un pointeur vers a0+truc
et
TRUC(a0), qui est le produit de truc par la valeur numérique du symbole a0 ?

Déjà, est-ce que c’est vraiment nécessaire de considérer que expr(identificateur) corresponde au produit expr × identificateur ?
Si oui, le plus simple serait d’interdire l’utilisation de a0 comme identificateur, c’est un mot réservé.

Donc si tu rencontres une expression de la forme expr * (registre) tu la rejettes, car ce n’est pas la même chose qu’une expression de la forme expr * (identificateur).

Oublié de préciser : une expression peut aussi être _ROM_CALL_xyz ou _RAM_CALL_xyz. MAis pour ça, je sais comment je vais faire je crois.

Pourquoi, quel est le problème ?

PpHd (./54) :
Martial, tu peux regarder ce que j'ai fait dans PedroM/MAYLIB aussi (parser.c).

Ouep... Ouep... mais le code C, je vais tellement mal le comprendre que je vais merder. Je vais voir comment tu fais les opérations dans PedroM.

Sasume (./57) :
Pourquoi, quel est le problème ?

Ben parce que c'est pas une valeur numérique. Ya d'autres données à retourner qu'un simple entier 32 bits, et derrière ya un relogement à pondre.

./58 Il y a un joli bloc de commentaires au début de la fonction may_parse_c

./59 Donc ce n’est pas une expression ^^