"Ecrire un assembleur pour les noobs" - Page 1

Il ne faut pas trop se fier au titre pourrave que j'ai choisi, mais bon...
Voilà un truc que j'ai écrit a propos du codage d'un assembleur en général. C'est principalement les idées que j'ai eu lorsque j'y ai réfléchi il y a quelques temps.
ça devrait pas intéresser grand monde (mais on sait jamais ^^), mais je voudrais avoir votre avis dessus, si jamais vous avez le temps de le lire
Quand a pourquoi j'ai écrit ça... Qui vivra verra... (ou pas !)

Lien vers le fichier texte

[EDIT] Bon en fait je laisse juste le lien au dessus...

j'ai l'impression que tu demandes bcp de prérequis et que tu passes très vite sur bcp bcp de choses pas évidentes, mais qu'à d'autres endroits tu détailles bcp certaines choses qui sont a priori assez évidentes pour qqun avec tous ces prérequis...

Ensuite je ne suis pas vraiment d'accord avec tes conseils, en pratique une fonction par instruction ça risque d'être bien trop verbeux... ce serait peut-être bien de rentrer dans les détails. Par exemple l'assembleur de GTC a en tout et pour tout 4 types d'instructions, les labels, les instructions "classiques", les sauts, et les instructions de déclarations de données brutes : si il fallait faire une fonction pour add, une autre pour addi, une autre pour addq, une autre pour adda, une autre pour sub, subi, etc... ce serait affreux Plus précisément, pour les instructions "classiques" j'utilise un moteur de pattern-matching : grosso modo c'est une liste de contraintes "si l'instruction est addq .b/.w/.l, que l'opérande source est une valeur immédiate (A_IMM), utiliser le masque 0x5000, mettre l'opérande source dans le champ D_Q, la taille dans le champ D_SZ et l'opérande destination dans le champ D_EA" C'est bien sûr un cas un peu particulier parce que l'assembleur 68000 est très régulier, place toujours ses opérandes à 2-3 endroits bien définis, etc..., mais ça permet d'avoir un code très compact et surtout de limiter les risques d'erreurs (j'ai dû avoir en tout et pour tout un bug sur une instruction rare où j'avais mal tapé le masque), et je pense que c'est une technique qui s'applique à plein d'autres plateformes...

Après tu passes *très* vite sur tout ce qui est résolution de labels, alors que je pense que c'est vraiment un point crucial de tout assembleur. Déjà, selon le but de l'assembleur, les contraintes vont varier : est-ce que je veux la performance à tout prix ? si oui, est-ce que mon assembleur doit optimiser "add.w #label2-label1,d0" en "addq.w #label2-label1,d0" quand c'est possible ? ou est-ce qu'au contraire je m'en tape complètement et je peux coder tous mes sauts sur 32/64 bits sans que ça soit gênant ? Si on est dans le dernier cas, pas de problème, il suffit de faire ça de façon bourrin. Sinon, il faut vraiment penser l'assembleur autour de l'optimisation des sauts, prévoir de faire plusieurs passes, etc...

Tu ne parles pas du tout non plus de ce que pourront contenir les opérandes, alors que c'est aussi un truc pas forcément évident. En pratique on va vouloir gérer des expressions littérales type C sur les entiers, pouvoir les évaluer au moment voulu, rajouter à tout ça les labels, peut-être même supporter les différences de labels (ou pas ? ça va dépendre du format objet choisi, c'est important), voire de supporter des calculs plus subtils sur les valeurs des labels (ou pas ? idem). Je ne parle pas non plus des equs et des macros...

Bref, j'espère que ton tuto servira à qqun, mais ça serait peut-être une bonne idée de le compléter, notamment en mettant en valeur les choix de conception qu'il faudra faire (quel format source : qui gère les macros ? [préprocesseur externe, intégré au langage, non supporté] ; quel format de sortie : linker intégré [utile surtout pour des plateformes embarquées pour lesquelles il n'y aurait pas de linker vraiment utilisable], ou format objet [si oui lequel ?] ; quelles optimisations : optimisation des sauts internes au fichier ? optimisation des instructions [style add->addq] ? si oui, est-ce que ça peut avoir des effets nocifs ? [par exemple a68k permet de désactiver certaines optimisations pour faciliter l'écriture de code auto-modifiant] optimisations plus avancées ? [add->addq quand l'opérande est une différence de labels])

Pollux
: j'ai l'impression que tu demandes bcp de prérequis et que tu passes très vite sur bcp bcp de choses pas évidentes, mais qu'à d'autres endroits tu détailles bcp certaines choses qui sont a priori assez évidentes pour qqun avec tous ces prérequis...

Hmm certainement, mais je crois pas être capable de voir ce genre de choses...

Ensuite je ne suis pas vraiment d'accord avec tes conseils, en pratique une fonction par instruction ça risque d'être bien trop verbeux... ce serait peut-être bien de rentrer dans les détails. Par exemple l'assembleur de GTC a en tout et pour tout 4 types d'instructions, les labels, les instructions "classiques", les sauts, et les instructions de déclarations de données brutes : si il fallait faire une fonction pour add, une autre pour addi, une autre pour addq, une autre pour adda, une autre pour sub, subi, etc... ce serait affreux Plus précisément, pour les instructions "classiques" j'utilise un moteur de pattern-matching : grosso modo c'est une liste de contraintes "si l'instruction est addq .b/.w/.l, que l'opérande source est une valeur immédiate (A_IMM), utiliser le masque 0x5000, mettre l'opérande source dans le champ D_Q, la taille dans le champ D_SZ et l'opérande destination dans le champ D_EA"

Bah a l'époque (il y a un... deux ans ?) j'avais cherché comment coder un assembleur 68k relativement rapidement, et après avoir regardé le code de as (assez immonde sur certains points ed la conception) puis de a68k qui m'avait paru assez gore aussi (mais là je sais plus pourquoi)...
Alors j'ai du réflechir à comment faire mieux et le seul truc qui m'est apparu c'est la solution que tu donnes... En fait j'avais fait un programme pour générer une table de données (truc immonde) en xml (j'ai dit immonde) mais j'ai buté sur je sais plus quelle connerie, parce que les instructions du 68k bien que régulières elle sont quand même pas toujours organisées très logiquement...
Donc en fait la technique 1 instruction = 1 fonction m'a paru la plus simple à mettre en place et à maintenir (sachant que je comptais le coder en C#), mais je peux me tromper. Je suppose que c'est un compromis entre optimisation (la technique de GTC donc) puisque j'utilise quand même une table, et simplicité d'écriture

C'est bien sûr un cas un peu particulier parce que l'assembleur 68000 est très régulier, place toujours ses opérandes à 2-3 endroits bien définis, etc..., mais ça permet d'avoir un code très compact et surtout de limiter les risques d'erreurs (j'ai dû avoir en tout et pour tout un bug sur une instruction rare où j'avais mal tapé le masque), et je pense que c'est une technique qui s'applique à plein d'autres plateformes...

A mon avis ça s'applique parfaitement (beaucoup mieux que pour les 68k du moins) a l'ARM7 de la GBA, et certainement l'ARM9 aussi, mais honnêtement j'ai des doutes pour une plateforme comme le x86... (Bon je connais pas en détail mais la dernière fois que j'avais regardé, ça m'avait parut complètement bordellique) En fait faudrait que je regarde les sources de divers assembleurs non-68k pour regarder les différentes manières de procéder

Après tu passes *très* vite sur tout ce qui est résolution de labels, alors que je pense que c'est vraiment un point crucial de tout assembleur. Déjà, selon le but de l'assembleur, les contraintes vont varier : est-ce que je veux la performance à tout prix ? si oui, est-ce que mon assembleur doit optimiser "add.w #label2-label1,d0" en "addq.w #label2-label1,d0" quand c'est possible ? ou est-ce qu'au contraire je m'en tape complètement et je peux coder tous mes sauts sur 32/64 bits sans que ça soit gênant ? Si on est dans le dernier cas, pas de problème, il suffit de faire ça de façon bourrin. Sinon, il faut vraiment penser l'assembleur autour de l'optimisation des sauts, prévoir de faire plusieurs passes, etc...

Ben d'une part j'ai oublié de dire que certains label se résolvent dans l'assembleur, et d'autre part c'est souvent le linker derrière qui s'occupe de la résolution des liens... Enfin oui j'ai oublié de parler de l'optimisation de taille, même si je l'ai en tête

Tu ne parles pas du tout non plus de ce que pourront contenir les opérandes, alors que c'est aussi un truc pas forcément évident. En pratique on va vouloir gérer des expressions littérales type C sur les entiers, pouvoir les évaluer au moment voulu, rajouter à tout ça les labels, peut-être même supporter les différences de labels (ou pas ? ça va dépendre du format objet choisi, c'est important), voire de supporter des calculs plus subtils sur les valeurs des labels (ou pas ? idem). Je ne parle pas non plus des equs et des macros...

Ben les expressions de type C j'avais pas pensé en parler parce que selon ce qu'on veut faire (genre si tu veux autoriser ((label1 * label2 + 3) * 4 + label1) / label2 c'est le bordel...) ça change du tout au tout. Les equ et les macro, ça y était au début, mais ça a giclé pendant l'écriture, parce que c'est purement du préprocessing (utile, mais pas nécéssaire), et ça se rajoute très bien par dessus le parsng de base... Enfin faut "juste" passer de 1 passe à 2 passes quoi.

Bref, j'espère que ton tuto servira à qqun

Si c'est aussi mauais que ce que tu as l'air de dire, j'espère que non... Enfin, perso que je code des tas de trucs qui partent à la poubelle 3 jours après ça me dérange pas (bon en fait si, je commence a en avoir un peu marre), mais si par ma faute ça arrive aux autres... :/

mais ça serait peut-être une bonne idée de le compléter, notamment en mettant en valeur les choix de conception qu'il faudra faire (quel format source : qui gère les macros ? [préprocesseur externe, intégré au langage, non supporté] ; quel format de sortie : linker intégré [utile surtout pour des plateformes embarquées pour lesquelles il n'y aurait pas de linker vraiment utilisable], ou format objet [si oui lequel ?]

Hmm c'était quand même plus un "plan de construction" qu'un guide complet mon truc :d
D'ailleurs je vais modifier le titre qui correspond pas trop...

quelles optimisations : optimisation des sauts internes au fichier ? optimisation des instructions [style add->addq] ? si oui, est-ce que ça peut avoir des effets nocifs ? [par exemple a68k permet de désactiver certaines optimisations pour faciliter l'écriture de code auto-modifiant] optimisations plus avancées ? [add->addq quand l'opérande est une différence de labels])

Je passe

GoldenCrystal
: Si c'est aussi mauais que ce que tu as l'air de dire, j'espère que non... Enfin, perso que je code des tas de trucs qui partent à la poubelle 3 jours après ça me dérange pas (bon en fait si, je commence a en avoir un peu marre), mais si par ma faute ça arrive aux autres... :/

J'ai pas dit ça C'est juste qu'il faut déjà avoir compris bcp de choses sur le fonctionnement d'un assembleur avant de pouvoir comprendre ton tuto je pense ^^

j'ai fait un assembleur 68k pour etp.. en visual basic6 :$

moi qui suis (était?) un noob, avec un langage de noob..

Ça a l'air intéressant, je n'ai pas lu l'article en question, seulement la critique de Pollux
Je pense que ça pourra m'être utile. Même si ce que tu mets n'était pas toujours pertinent, ça nourrirait quand même ma réflexion.
(Je reviendrai là-dessus plus tard, quand j'aurai du temps)

Kevin Kofler
Ecrit le: Mercredi 26 juillet 2006 à 01:27
Lancelot : Je crois que ça va vous intéresser ^^

[Zeph] supprimé, en attendant que je trouve le lien sur tigen correspondant

[Zeph] trouvé : lien

Lancelot, rien ne t'autorise à copier ce texte.

et au passage, même si c'était le cas, Kevin Kofler est banni de ce forum... c'est pas pour y voir des copier-coller de ses posts...

Il a pas changé Kevin ! Il a toujours pas compris que les gens programment pour leur plaisir.

Merci pour ta très bonne introduction Golden

Je dirais que le l'article de GC a pour but d'expliquer comment marche un assembleur, tandis que celui de KK a pour but d'expliquer comment en faire un.
La théorie vs la pratique quoi

Y'a quand même dans le texte (du ./1) quelques précisions erronnées.Par exemple :

l'assembleur n'apporte aucun avantage par rapport à un langage de niveau plus élevé, comme le C par exemple, puisque de nos jours les compilateurs permettent bon nombre d'optimisations et produisent du code aussi performat

C'est pas complètement vrai : tout ce qui est développement système ou utilisation de jeux d'instructions assez spécifiques nécessite de l'assembleur, même si ce n'est qu'une petite fonction dans un gros logiciel en autre chose.

D'autre part même en terme de performances, il existe des optimisations réalisables par les développeur, mais pas automatisables, pour la simple raison que le développeur connait plus de choses sur ce qu'il doit réaliser que le compilateur. Je pense par exemple au dépliage de boucle externe. A contrario, ce type d'optimisation peut être faite en C directement. Mon point essentiel est qu'il ne faut pas aveuglément reposer sur le compilateur.

Bien entendu, je suis d'accord que dans la grande majorité des cas, le code fourni par le compilateur est aussi bon que celui qu'aurait écrit le développeur...probablement meilleur étant donné la forte propension du développeur à coder avant et réfléchir après.

(sans parler du fait que le développeur aura peut-être du mal à gérer lui-même l'ordonnancement des instructions sur x étages de pipeline, etc)

vous dites ca à l'heure où "tout le monde" utilise un compilateur avec lequel il vaut mieux écrire

for (i=n;i--; )=n;i>0;i--); plutot que for(i
??

sans parler que si on compile des langages à exceptions vers C, la récursion terminale avec gestion des exceptions n'est pas possible en C dans tous les cas alors qu'en assembleur, on peut, mais là je pinaille...

On s'en fout de ce que dixit KK. ^^

lancelot, si t'es seulement là pour copier coller les messages de KK ici, je préfere autant prévenir tout de suite : on va pas s'entendre... KK il est sur Tigen, si qqun a vraiment envie de se prendre la tête ac lui, qu'il aille sur Tigen, je ne veux pas voir ses messages ici.

[HS] dommage que j'ai pas de compte sur tigen, je lui aurais bien répondu des trucs, mais flemme & co bref.. tant pis[/hs]

[HS aussi] Mon Dieu, vous avez vu sa signature ? Il n'a absolument pris aucune leçon du passé. Comment peut-on être aussi méchant envers les autres et leur travail ? Ca me dépasse.

Bon, ça y est, j'ai lu

En fait, c'est marrant, j'avais déjà un peu réfléchi à la conception d'un assembleur (pour 68000 bien sûr), mais je ne m'étais pas du tout attardé sur cet aspect de l'assemblage, j'avais passé beaucoup plus de temps à réfléchir au parsing parce que je pensais que c'était surtout là-dedans que le temps d'exécution pourrait être diminué (par rapport à AS de nitro).
Après pour la génération du code, j'avais vaguement pensé faire quelque chose comme ce qu'indique Pollux, mais sans vraiment préciser mon idée.

Finalement lire ce topic (ton article et la discussion qui suit, avec Pollux), a été plutôt intéressant pour moi

[Furtif]
Tout comme Sasume : j'avoue que cette discussion n'est pas tombée dans {l'oreille d'un sourd/les yeux d'un aveugle}
[/Furtif]

Bref si tu comptes faire des modifs a ton tuto GoldenCrystal, tu pourra au moins etre sûr d'une chose c'est que t'aura un lecteur ^^