Manuel de l'assembleur 32/64 bits GoAsm : traduction intégrale en français, par Robert Cordonnier

Manuel de l'assembleur 32/64 bits GoAsm
Traduction intégrale en français de la première partie, par Robert Cordonnier

Ce document constitue la première partie de la traduction française intégrale du manuel de l'assembleur 32/64 bits GoAsm, développé par Jeremy Gordon avec la collaboration de Wayne J. Radburn.

http://asm.developpez.com/manuels/ma...oToolsLogo.gif

:fleche: https://asm.developpez.com/manuels/manuel-goasm/

Je pense m'exprimer au nom de toute la communauté en remerciant Robert Cordonnier pour ce colossal travail et pour la qualité de sa traduction. :ave:

Et vous ?
:arrow: Connaissez-vous l'assembleur GoAsm ?
:arrow: Que pensez-vous de l'initiative de Robert Cordonnier de mettre ce document à la disposition du public francophone ?
:arrow: Êtes-vous prêt(e)s à participer à la traduction d'autres ressources sur l'assembleur ?

Pour ma part je ne connaissais pas cet assembleur !
Je ne suis pas contre un tutoriel sur du x64 , mais je félicite le travail monstrueux pour ce document.

Néanmoins j'ai du mal à voir l’intérêt de cet outil :
- Il est spécifique à Windows et ces IDE conseillés aussi...
- Le cours explique que GOASM est fait uniquement pour les plateformes Windows 32/64 bits
- Par expérience perso, ce qui me permet de coder rapidement en asm c'est les Macro et les labels temporaires, je ne trouve pas GOASM meilleur que d'autres assembleurs sur ce point la (mais effectivement c’est mieux que NASM ou GNU assembleur)

Voilà en gros mon point de vue , j'ai l'impression que le but de ces outils c’est de faire des applis Windows avec une syntaxe assembleur :aie:
Du coup je ne lui trouve aucun intérêt, sans parler que sur un processeur complexe comme le x86 , les processeurs avec pipeline, en ayant fait personnellement l'expérience sont clairement plus compliqués à optimiser que si on utilise un compilateur.

EDIT:
Par contre je trouve que les raisons sont assez fausses :

Citation:

---

Il y a plusieurs raisons pour lesquelles il peut être intéressant de recourir à un langage de si bas niveau.

Taille : en codant à ce faible niveau, vous pouvez réduire le code à un strict minimum inatteignable même par les compilateurs les plus performants.
Vitesse : une taille de code réduite au strict nécessaire signifie que vos programmes se chargent et s'exécutent plus rapidement.
Contrôle : vous contrôlez totalement le code, à la différence d'un compilateur. Cela signifie que vous savez exactement ce que le processeur est en train de faire lorsqu'il évolue à travers votre code. Cela permet d'obtenir un résultat probant et de repérer les erreurs plus facilement.

---

Taille: Oui et non sauf pour certain vieux compilateur , je ne pense pas que quelque kilo octet soit très important de nos jours (sauf pour des micro contrôleur , mais ici on parle de programmation sur PC en 2017...).
Mais les compilateur font du bon boulot , un jeux vidéo assez conséquent sur Super Nintendo (en full assembleur ) pouvait me prendre 80 kilo octet (niveau code pas la rom qui prend facile quelque MO ) , sur PC j'avais fait un jeu 3D il me faisait 100ko :roll:
Mais oui l'assembleur permet plus facilement controler la taille de son exécutable (j’avait fait un moment un driver sonore avec 4ko , en full asm ).

Vitesse: c'est la qui m’inquiète le plus parce que la phrase est totalement fausse , un code réduit en général veut dire un code moins optimisé :roll:
Par exemple le dépliage des boucles ça prend de la place mais c'est largement plus performant !
Les Macro , ça évite les call /ret/ la pile ou les arguments et donc plus performant mais ça prend rapidement de la place aussi.
Quand on precalcul , si on met le résultat dans le binaire (ou qu'on fait un code qui precalcul ) cela prend plus de place mais plus rapide que de faire les calcul en temps réel !
L'autre point la pipeline , 4 instruction qui fait des pipeline stall et 8 sans pipeline stall sera plus rapide...


Contrôle: Vrai ou pas , les compilateur C permet de voir le code assembleur (que je fais souvent a titre perso , rien que pour voir si je fait mieux que lui :mouarf: ) , je dirais que a force on peut savoir a l'avance comment le compilateur optimise si on le connaît suffisamment bien :)
Par contre l'assembleur qui permet de repérer facilement les erreurs sûrement une blague , pour ma part j'applique la même méthodique qu'en C , une très grande rigueur et donc éviter au maximum les erreurs mais franchement je prefere éviter de debuguer un code asm manuellement.

Merci Kannagi pour tes commentaires très fouillés.

Juste quelques remarques de ma part :

1) Je m'intéresse à l'assembleur depuis quelques décennies. J'ai toujours fui comme la peste les débats sur l'intérêt de l'assembleur. Déjà, dans les années 80/90, il y avait les pour et les contre, surtout avec l'arrivée du C. Il y a eu les mêmes débats avec le Basic et ses langages concurrents, le tout agrémenté de questions cruciales telles que, par exemple, le fait de bannir ou non l'instruction "Go to", signe évident pour certains d'une programmation "déviante". Toujours est-il qu'il y a eu quelques langages "d'avenir" qui se sont finalement perdus dans la nuit des temps malgré des débuts prometteurs. Le meilleur langage étant toujours, de mon point de vue, celui avec lequel on se sent à l'aise...
2) Il reste que certains compilateurs d'aujourd'hui tiennent réellement la route comme le C++ d'Intel, par exemple, qui semble être un modèle du genre. Cette situation n'est cependant que relativement récente et ne concerne que certains compilateurs professionnels.
3) Sur l'optimisation du code, il suffit de parcourir le bouquin d'optimisation de code d'Intel ou d'AMD pour se convaincre que les dépliages de boucles et autres techniques de répétition de code sont efficaces sauf que la durée d'exécution dont je parle ici globalise la lecture du disque et le chargement du code. Mais il est vrai qu'avec les disques durs ultra rapides d'aujourd'hui, ce paramètre est moins crucial. Mais bon, il ne faut pas s'exciter sur ce point. On met de la rapidité là où c'est nécessaire mais pas plus. Pour ma part, je n'optimise que lorsque c'est crucial et ça l'est rarement, à vrai dire sauf à œuvrer dans des domaines tels que le traitement audio/vidéo, les calculs mathématiques complexes, etc...
4) Je n'ai pas très bien compris ta remarque sur les IDE. Oui, il s'agit "seulement" de Windows mais... What else, suis-je tenté de demander ? Ces outils sont bien destinés à faire des applis Windows avec une syntaxe assembleur. Mais, que fait de plus le C++ qui ne fait qu'appeler rigoureusement les mêmes API avec une syntaxe à peine plus sobre ? D'autant plus que le concept "Visual" développé par les IDE mentionnés simplifie considérablement l'interface utilisateur. Pour ma part, je procède énormément par copier/coller qui est la méthode d'écriture de programme la plus efficace !

Pour conclure, je me suis intéressé à cet assembleur pour 5 raisons:

- sa syntaxe est pratique (PUSH et POP multiples)
- gestion pratique des messages (ex : PUSH 'Bonjour' au lieu d'une déclaration en bonne et due forme du message dans le section de donnée suivie d'un PUSH sur l'offset du même message)
- la double plateforme 32/64 bits
- une bonne couverture des instructions de processeur les plus récentes
- une doc assez fouillée plutôt rare, dans ce domaine, il faut bien le reconnaitre.

Et une sixième en prime : j'aime bien l'assembleur ! (là, j'ai l'impression d'avoir avoué que j'ai fumé des substances illicites en cachette. Un "coming out", en quelque sorte.)

En tout cas, merci encore pour l'intérêt que tu as porté à ce travail
Bien cordialement
Robert Cordonnier aka Asmou

Pour te répondre :

1 et 6) Ton cas est particulier , tu apprécie l'assembleur et c'est le seul langage que tu maîtrise , mais bon c'est pas forcément le cas de tout le monde.
Maintenant que tu aime l'assembleur c'est cool ,moi aussi avec le bas niveau.
Voila mon expérience personnelle en assembleur et le bas niveau (sur chaque machine j'ai tapé dans les I/O ) :
6502 : Nes , Pc Engine , Super Nes
M68000 : Mega Drive , Neo Geo , Atari ST , Taito F3
z80 : processeur sonore , master system
MIPS : Playstation 2 , Nintendo 64 , Hyper Neo Geo 64
et d'autre que j'ai pas forcément en tête , bref ma critique n'ai pas de quelqu'un qui n'aime pas l'assembleur , je le trouve intéressant et assez pratique dans certain cas (et mon cas ici est qu'il est facile avec l'assembleur de sauter de machine différente , en C il faut configurer le compilateur plus chiant) de plus pour tester du petit code sur une machine ayant peu de doc , savoir le fonctionnement de A à Z est assez utile.
Et c'est fun il est vrai dans certain cas (je mentirai si j’apprécierai l'assembleur de manière universelle ) , mais c'est pareil pour le C (mon langage de prédilection).

2) Ce n'est pas le meilleur mais GCC en -03 se débrouille très bien aussi !

3) oui je te rassure j'optimise que les parties critiques , sauf sur certaine machine ou j'optimise quasiment tout (quand tu a quelque mhz ...).
Par contre l'optimisation la plus importante pour ma part sur les processeur moderne c'est la pipeline et je vois pas ou c'est forcément jouissif , voila mon expérience perso :

Citation:

---

Alors si tu programme en assembleur ça donnerai que tu devrai avoir a chaque instruction en tète la pipeline et donc avoir une idée de la pipeline pour chaque instruction , t'imagine le truc ? En plus ça t'oblige a réécrire ton code si tu veux faire une modif , parce que oui la modif ça peut chamboulé cette maudite pipeline !

D'ailleurs toute la difficulté du processeur de la PS2 était le VU0 et VU1 outre que c'était des co-processeurs 128 bits , il était superscalaire ,évité les pipeline stall sur deux instructions en même temps c'était comment dire très chiants
Mon but était de réduire l'instruction Div en 1 cycle (elle devait faire 6 cycle sur le VU) , ça permettait au final de faire des calcul de projection 3D/2D(pour l'écran) en quelque cycle !
D'ailleurs je me disait qu'il fallait créer un macro assembleur pour pas ce soucier de cette pipeline , bref de laisser un programme s'occuper de cette optimisation , ah oui ça existe presque deja c'est le C
Alors sur PS2 il existait pas de compilateur C pour ces VU et puis il fallait codé de manière assez bas niveau sur quelque octet alors autant aller en asm , mais il est clair que on passais des heures pour optimiser quelque ligne a la con...

Je dirais qu'en 1995 a cette époque les processeurs ont commencé a avoir une pipeline et tu pouvait bien faire sur ps2 un calcul matriciel en 4 cycle (4 instruction ) et la je parle d'un processeur qui date du siècle dernier (1999).

---

Une réponse que j'avais donné sur les compilateurs sur le forum C++.

4) ben c'est la que tu va comprendre peut être mon point de vue , pour résoudre un probleme il faut utiliser le bon outil , faire des appli en asm (certes toi tu aime ça et tu connais bien le langage) n'est pas le bon outil !
Déjà l'asm n'est pas portable , qu'il soit en plus orienté que pour un OS de mon point de vue c'est une faiblesse pas une force , j'utilise dis toi le même assembleur quand je code pour plusieurs machine , que le programme assembleur soit multi-plate forme est important pour moi , quand je partage du code (via GitHub) je peux me dire que peu importe L'OS tu arrivera a compiler mon code ( voir dans 50 ans cela sera toujours possible parce que justement le programme assembleur que j'utilise est écrit en C ).

NT: Attention je ne dis pas que tu dois changer de langage , mais pour ma part faut être honnête certain prog en assembleur save que c'est juste un loisir , inutile de donner des qualités en disant que c'est plus rapide ou que ton code sera drôlement plus petit.

Citation:

---

NT: Attention je ne dis pas que tu dois changer de langage , mais pour ma part faut être honnête certain prog en assembleur save que c'est juste un loisir , inutile de donner des qualités en disant que c'est plus rapide ou que ton code sera drôlement plus petit.

---

Disons que c'est ton avis personnel, sans plus...

Et enfin, je ne programme pas qu'en assembleur. Je ne sais pas où tu as lu ça ! Globalement, je l'utilise même de manière plutôt marginale. Je pense que tu conviendras avec moi qu'il est difficile d'imaginer un programmeur débutant se plongeant d'emblée dans les "délices" de l'assembleur.

Citation:

---

Envoyé par Asmou

Disons que c'est ton avis personnel, sans plus...

---

Mon avis personnel ?
Je suis assez étonné que ce genre d'affirmation est passé la relecture technique , c'est un forum de professionnel est il est normal que les affirmation erroné soit pris en compte :roll:

Bonjour Kannagi,

J'ai du mal à comprendre où le bât blesse. Que tu ne trouves pas d'intérêt à l'assembleur GoAsm est un avis personnel, aussi respectable que celui des utilisateurs du produit. Le traducteur du manuel de GoAsm ne vend rien, n'essaie de convaincre personne qu'il s'agit du meilleur assembleur de l'univers ; il a juste donné de son temps et de son énergie au bénéfice de la communauté. Il travaille sur d'autres traductions, dont certaines rencontreront peut-être ton intérêt... et laisseront d'autres de marbre.

Si tu constates des erreurs ou si tu n'es pas d'accord avec certaines affirmations de Jeremy Gordon et Wayne J. Radburn (ce qui semble être le cas), ou si tu souhaites faire part de ta désapprobation ou de ton désintérêt pour GoAsm, pourquoi ne pas t'adresser directement à son concepteur et/ou à sa communauté, au travers des liens qui sont donnés dans le manuel ?

;)

Alors j'ai deja donne mon avis sur GoAsm et qu’on a un avis différent du mien sur cet assembleur ne me gêne pas ;)
Si je les ai souligné j'ai parce que je pensé que cela était utile de les dires :)
(si ton message fait référence a mon second message du topic , j'ai tout simplement détaillé mon point de vue , j'avais l'impression que certain point de vue était mal compris mais le principal argumentation venait des affirmations fausses).

Ce qui me dérange néanmoins plus c'est que je relève plusieurs affirmation fausse alors oui je pourrais me plaindre directement au concepteur , mais d'un coté certaine personne ont voulu publier ces affirmation fausse ici non ?
C'est la seule chose qui me gêne a vrai dire , a la limite qu'on me dise "oui on a voulu tout traduire même les mauvaises choses" pourquoi pas , mais qu'on nie je trouve cela contre productif !

Je participe activement sur le forum je donne des indications au débutant , si les débutants viennent ici en se trompant sur les info du langage assembleur , c'est d'une part de notre faute (je dis cela parce que deja que je vois souvent sur le forum des personne venant de Open ClassRoom qu'il faut réorienté sur les bon cours a cause de mauvaise pratique ou mauvaise information d'un tuto).

J’espère que tu comprendra ce qui me gêne ;)

Il n'est évidemment pas question de nier quoi que ce soit si des erreurs existent dans le manuel. Elles ne sont pas du fait du traducteur, ne tirons pas sur le pianiste. ;)

Le présent fil de discussion est destiné à permettre aux lecteurs d'exprimer leurs remarques ; les tiennes susciteront donc la réflexion ou serviront de mise en garde.