« - yAronet - Attention : forum addictif !

23.01.2004 - 11605

21:38 Folco - Posté : 21-07-2008

Très très intéressant ! #top#

On n'a pas du tout la même approche. Je suis parti très vite dans les détails de m'implémentation, parce que c'est plutôt ça qui me fait epur en effet. Mais reprenons ce que tu as dit :

Sasume (./54) :

Il faut au moins designer TriList quand même, non ?
Qu'appelles-tu "designer" ?

Fraire le design de la fonction, en fait, j'écris toujours une phrase de descrpition + ce que ça prend en entrée + ce que ça pond en sortie + ce que ça détruit. Ca peut ressembler à ça (même si là c'est un exit, donc un peu particulier ^^) :

;================================================================== 
;	QuitError 
;================================================================== 
;	Terminate the execution, cleaning some handle and files, 
;	and throwing a message to stdout. 
;	Don't clear the stack frame, the loader will do it. 
; 
;	input	(sp)	*main string 
;		4(sp)	*args eventually 
;		8(sp)	... 
;		d7	constant to add to clear the stack 
;	output	output a string to stdout 
;	destroy	some data, but osef 
;==================================================================

Sasume (./54) :
C'est-à-dire ? Assembler plusieurs fichiers .asm et les coller bout à bout au moment de l'édition de liens ? Ou bien gérer l'inclusion de fichiers ?

Les deux mon colonel. Une inclusion, t'es obligé de la gérer pour les headers. L'édition des liens, je suis obligé de la faire pour être réellement milti-source (car inclure des sources revient en fait à n'en avoir qu'un seul. Le problème vient des programmeurs gore qui foutent du code dans les headers. Un headers simplement fait de définitions et de macros pourrait juste être ouvert, pour qu'on pioche dedans en cas de symbole inconnu. A cause de ceux qui y écrivent du cde qui doit être inclus au moment de l'inclusion précisément, c'est pas possible, et donc de là il faut include récursivement pour compléter le source, car la fichier inclus peut en inclure d'autres. (ça me fait penser qeu ce que j'ai dit plus haut est faux, on ne peut pas ouvrir un header juste en read-only à cause de ça...)

Sasume (./54) :
Au fait, tu ne comptes pas séparer l'assemblage de l'édition des liens ?

Si, sinon tu peux pas gérer plusieurs sources qui ont des références croisées (et il y en a forcément dans le cas de vrai multi-source, ie sans inclusions bourrines).

Sasume (./54) :
Ces deux points se rejoignent non ? Je les aurais écrits sur la même ligne Sinon, tu n'as pas parlé de lib, mais j'imagine que tu y songeais aussi non ?

ben disons que créer du nostub est facile, qui peut le plus peut le moins, le kernel n'est qu'un wrapper (header) autour d'un binaire nostub (à l'exception des relogements kernels essentiellement, + ram calls, bss etc...)

Sasume (./54) :
Quels types de mots peux-tu rencontrer (instructions, labels, opérandes, directives préprocesseur, etc.)

Pour moi c'est pareil en fait. Comment ça c'est pas bien ?

Tous les mots connus sont référencés dans un table, de move à include en passant par xdef. Si c'est une instruction, je l'assemble. Si c'est un xdef, j'ajoute un export etc... Donc à la base, je me fous de ce que je vais trouver, c'est la même moulinette qui lit, et qui ensuite lance ce qu'il faut par rapprot à ce qu'elle a trouvé.

Sasume (./54) :
comment gérer toutes les entrées possible sans écrire un code trop spaghetti ? Surtout que, en outre, tu devras être capable de détecter et gérer les erreurs de syntaxe !

Ca c'est tout con, c'est la table des instructions qui le gère, essaye move.w 7d,d0 et ça t'enverra chier (si t'as pas de variable 7d), essaye move.l d0/2,d1, ça va valser aussi. Ou encore cmpi d0,d1. La table est faire pour ne permettre que ce qui est permis par la doc.

Sasume (./54) :
Mais tu peux aussi tout faire en une seule passe, mais ça implique quelques limitations : le programmeur ne pourra pas faire d'appel de macro sans avoir défini la macro auparavant, idem pour les equ, etc.

Je ne comprends pas pourquoi, s'il a inclus son header, voire son source dans lequel la macro est définie, pourquoi ça passerait pas ? Tu dois pas voir les choses comme ça j'imagine ?

Sasume (./54) :
genre ce fichier source contient une directive include, suivie d'une chaîne contenant preos.h, suivie d'un retour à la ligne, suivi d'un identificateur (un nom) ayant pour valeur main, suivi de deux points, suivi d'un retour à la ligne, suivi d'une tabulation, suivi d'un nom d'instruction, suivie d'un point, suivie d'une taille d'opérande correspondant à byte, suivie du signe dièse, suivi d'un nombre, suivi d'une virgule, suivie d'un nom de registre, etc. un peu comme si dans une phrase en français tu décortiquais la nature de mots utilisés et de la ponctuation),

Je vois pas l'intérêt de faire ça, au moins pour de l'assembleur. Etant donné qu'on ne peut passer que ce qui se résume à du source (source, macro), à du préprocessing (ifdef) ou généralement à des "commandes" (terme mal choisi, mais je parle aussi bien de xdef que de include), quel est l'intérêt de l'analyse lexicale ?

Sasume (./54) :
sur Internet tu pourras trouver des ressources là-dessus

Tu m'avais déjà filé un lien très précis, mais qui ne marchait pas sur le moment, désolé ... #tsss#

Sasume (./54) :
Il serait judicieux de les ranger dans une table, au fur et à mesure où tu les rencontres, et où tu notes toutes les infos que tu as sur eux (par exemple quand tu rencontre le texte SIZE equ 12, tu dois stocker dans ta table de symboles que l'identificateur SIZE correspond à un equ et a pour valeur le texte "12"

L'autre solution étant de reparcourir le source, ainsi que les "include" qu'il contient #tripo#

Et attention aux inclusions circulaires, vu que c'est récursif à priori, sawashié ! #tripo#

Plus sérieusement, ta table me convient, mais j'ai peur de la consommation de RAM après avoir lu un header tel que tios.h ...