Sasume (./19) :
Ça me semble bien dans l’idée, je pense que tu peux même écrire directement dans le fichier de sortie (qui ne sera peut-être pas l’exécutable si tu fais une édition de liens ensuite, ou si tu veux gérer le format kernel).

Exact, j'ai un handle pour le binaire, je devrais pouvoir écrire dedans directement, au moins le masque de l'instruction. Parce que j'ai pas encore regardé, mais si les adressages en <truc.size> x(an),y(am) s'écrivent "à l'envers" dans le binaire, il faut attendre d'avoir parsé la seconde opérande pour savoir où écrire les offsets. Mais c'est pas un problème, j'ai un stack frame global au programme, suffit de les mettre dedans.

Sasume (./19) :
Pour ce qui est des labels, tu dois simplement construire une table de symbles au fur et à mesure de l’assemblage, dans laquelle tu notes à quoi correspond chaque déclaration de label que tu croises (où il est physiquement et où il est utilisé).

Je note son emplacement, un checksum (pour rechercher plus vite). A voir si j'y rajoute un tag d'exportation au début du linking, pour éviter de rechercher à chaque fois dans la table des xdef.

Sasume (./19) :
Quand tu dois calculer un saut, tu regardes si le label auquel le saut fait référence est déjà dans ta table, si oui tu calcules la distance du saut, sinon tu notes le fait qu’il est utilisé à cet endroit comme ça quand tu trouveras sa définition plus bas tu rempliras la valeur du déplacement. Ça te permet d’assembler en une seule passe.

C'est dur de calculer même si le label est avant, on peut très bien avoir des références non résolues entre les deux (sauts relatifs longs ou courts. Je ne parle pas encore d'adressage de BSS sur 2 ou 4 octets .

Quitte à devoir faire un linker, autant tout faire à ce moment, à mon avis.