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
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 :
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
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é
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
) , 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.
1 |
0 |