Discussion :

[CLion]

bonjour
je cherche un bon tutorial qui peux me faire apprendre l'assembleur depuit le 0 jusqu'a la realisation d'un projet.

et si c'est possible je veux qu'il soit sous Visual c++, sinon je m'en fous jeveux juste la bonne explication et la realisation d'un projet pour pratiquer ce qu'on apprendre, merci

[ac_wingless]

Je pense que d'autres le diront mieux: il est très sérieusement déconseillé de travailler en assembleur en 2007. Même l'aspect formatteur de la chose, autrefois peut-être justifié (mon premier gros programme de 8600 lignes d'assembleur 6809 m'a formé à une rigueur probablement utile à mes débuts sous Unix), n'est plus vrai aujourd'hui: la fameuse "rigueur", acquise sur 6809 à coup de réinitialisation complète depuis le lecteur de cassettes audio à chaque virgule fausse, ne me sert plus du tout, même lorsque je travaille sur des systèmes embarqués.
Dans ma boite on me refile tout ce qui touche à l'assembleur, et pourtant je ne suis mis à contribution (tous les quelques mois) que pour gratter quelques pas dans des microcontrôleurs bas de gamme, où l'objectif de prix du projet est de réduire le prix de la carte de 2.33 euros à 2.28 euros en changeant de série de MC... et encore, le coeur du programme est en C, et je farfouille juste sur les points durs. Avec la dégringolade des coût de l'intelligence embarquée, ce sera fini dans 6 mois.
De toute façon, les nouveaux processeurs ne fonctionnent vraiment plus de nos jours comme la génération pre-pentium. On a en particulier des DSP récents qui sont totalement improgrammables par les humains.

Je reconnais que l'assembleur peut être assez fun, un peu comme la conduite avec une boite de vitesse européenne opposée à une automatique. Mais même pour gouter aux joies d'antan avec du matériel moderne, je recommande plutôt les shaders de DirectX 10 (et pas 9). C'est un peu le même look&feel (on définit exactement les séquences que l'électronique va effectuer), mais par contre ça dépote des centaines de GFlops, et en plus c'est joli sur l'écran.

[Mat.M]

et si c'est possible je veux qu'il soit sous Visual c++, sinon je m'en fous jeveux juste la bonne explication et la realisation d'un projet pour pratiquer ce qu'on apprendre, merci

Avec VC++ dans un projet tu peux mêler de l'asm inline.
Sinon il ya NASM ; pour apprendre soit tu cherches un tuto il y a un forum assembleur soit un bon bouquin.
Mais c'est vrai que c'est un peu dépassé on peut programmer directement les cartes vidéos en C graphique je crois

[shenron666]

Je pense que d'autres le diront mieux: il est très sérieusement déconseillé de travailler en assembleur en 2007.

tout programmeur sensé serait en désaccord avec toi
pour ce qui est de développer un projet complet de a à z en assembleur c'est de la folie, certes
mais si tu fais du traitement et que tu as une fonction lourde genre calcul de matrice appelée plusieurs fois par secondes, rien que le fait de la passer en assembleur peux diviser par au moins 4 le temps de traitement
l'assembleur c'est pour de l'optimisation, et comme Mat.M le dit si bien, tu peux inliner de l'asm dans du C++ sous visual

commences par regarder les resources disponibles ici :
http://asm.developpez.com/
tu y trouvera certainement ton bonheur

[ac_wingless]

mais si tu fais du traitement et que tu as une fonction lourde genre calcul de matrice appelée plusieurs fois par secondes, rien que le fait de la passer en assembleur peux diviser par au moins 4 le temps de traitement

C'est une idée assez répandue, car c'était vrai il y a une quinzaine d'années, mais c'est faux aujourd'hui. Par exemple, j'ai passé un calcul particulier de matrices quasi-vides de très grandes tailles entièrement en assembleur en 1992, gagnant un facteur 3.2 sur le meilleur compilateur FORTRAN de l'époque (ça m'a quand même pris des semaines de boulot). Lorsque les premiers Pentium sont sortis, j'ai tenté de battre de nouveau le compilateur, et j'ai échoué. J'ai certes amélioré ma propre compétence à l'occasion, en particulier depuis j'ai une bonne compréhension de l'organisation des structures mémoire pour faciliter les caches et la pagination. Ca n'empêche que même sur un processeur dit "classique", les unités en parallèle (dans un même coeur!), les pré-fetch, les branchement prédictifs adaptatifs, les instructions spéciales SSE et tout un tas de gestion subtiles de caches avec zones avec lock d'écriture qui lisent plus vite et autres farces mal documentées, il devient délirant d'essayer de battre un compilateur moderne sur une opération de grande taille comme un algorithme matriciel, et bien sûr encore plus sur des opérations de petites tailles pour lesquels les compilateurs font de véritables mesures sur la totalité des alternatives et sélectionnent la meilleure sur des critères heuristiques utilisant des connaissances non publiques. En particulier, je mets au défi quiconque de battre le compilateur Intel sur processeur Intel récent, pour n'importe quel algorithme en C++ de quelques dizaines de lignes. Sérieusement, me contacter par MP, on parie une bouteille de champagne, je serais ravi de perdre en fait, ça me consolerait sur les capacités des humains.

Selon moi, tant qu'à vouloir optimiser, outre le parallèlisme avec OpenMp ou TBB, il vaut mieux se familiariser avec les Shaders, y compris pour des applications non graphiques, car déjà avec DirectX 10, mais surtout avec les petites infos qui filtrent de DirectX 11 et d'autres travaux plus publics (chez AMD en particulier), le futur du calcul intensif passe par la mise en commun des resources des CPU et GPU pour les applications généralistes.

L'assembleur sur ordinateur est mort, vive les Shaders!
(L'assembleur sur microcontroleur a encore un certain avenir par contre.)

[deadalnix]

La grosse difference avec il y a quelques années, c'est qu'aujourd'hui, memem nos x86 ont un coeur RISC meme s'ils acceptent un jeu d'insctruction CISC.

Pourquoi ?

Le jeu d'instruction CISC est plus facile a gerer pour l'hummain, ce qui a ete un plus au temps ou on faisait tout en assembleur, mais ce jeu d'instruction est plus dur a gerer pour l'electronique, qui du coup est plus lente, et est aussi plus difficile a gerer pour les compilateurs.

Maintenant presque tout le code est generé via compilation, et le recours aux instructions de type CISC sont tres rares sur nos applications. Du coup les processeurs se sont adaptés. Maintant, ils ont un coeur RISC, et quand ils recoivent des instructions qu'il ne peut pas traiter, ils les convertissent en plusieurs instructions COSC.

En bref, le code ecris en assembleur a la main est que tres tres rarement plus rapide car le coeur du CPU n'est plus du tout le meme.

Concernant les cour d'assembleurs, car ils ont tout de meme un interret pedagogique, tu peux trouver un tas de trucs ici : http://asm.developpez.com/

c'est vrai que c'est pas tres bien linké, et qu'il faut savoir que c'est la

[Kujara]

En particulier, je mets au défi quiconque de battre le compilateur Intel sur processeur Intel récent, pour n'importe quel algorithme en C++ de quelques dizaines de lignes.

Fait attention a ce que tu dis ....

J'ai pas testé le compilo intel, mais le vc++ derniere version est très, mais alors très très loin d'optimiser parfaitement un algo de plus de 5 lignes.

J'ai gagné vitesse x 140 sur un algo de 40 lignes, en modifiant l'algo certes, mais si on considère juste l'implementation ( donc quelque chose que le compilo peut faire), je gagne x 10, quand même ... et ça c'est sans inline asm.

[deadalnix]

Sur des trucs tres particulier en effet. mais sur tout un programme, avec les memes algos, c'est cuit.

D'ailleur sur la majeure parties des algos c'est cuit.

PS: mode debug ou optimisé la compilation ? car ca fait toute la difference (perso j'utilise gcc, mais je suppose que VC++ est capable de ce genre de choses aussi).

[Kujara]

PS: mode debug ou optimisé la compilation ? car ca fait toute la difference (perso j'utilise gcc, mais je suppose que VC++ est capable de ce genre de choses aussi).

Mode full optimisations bien sur.

Sur des trucs tres particulier en effet. mais sur tout un programme, avec les memes algos, c'est cuit.

Je ne comprends pas cette phrase.

D'ailleur sur la majeure parties des algos c'est cuit.

Ca depends des algos.

Pour tous les trucs courants on a la stl, boost, et les autres librairies pseudo standards, donc déja optimisé.

Pour les algo bien complexes, laisser faire le compilateur en se disant qu'il optimisera tout seul, c'est pas seulement une preuve de stupidité crasse, c'est d'un anti-professionalisme aigu ....

C'est un coup a se retrouver avec un moteur graphique qui affichent du doom 2 a 10 fps sans comprendre pourquoi ....

[shenron666]

Sur des trucs tres particulier en effet. mais sur tout un programme, avec les memes algos, c'est cuit.

comme je le disais dans mon précédent post, inutile de développer un programme complet en assembleur aujourd'hui

une fonction qui sera appelée plusieurs centaines,milliers...de fois par seconde peut avoir besoin d'un petit coup de pouce car, contrairement à ce que tu crois, les compilateurs ont beau être très performants aujourd'hui ils ne remplacent toujours pas un cerveau humain et un programmeur assembleur qui sait ce qu'il fait est capable de faire mieux que n'importe quel compilateur

[deadalnix]

Kujara > ce que je voulais, c'est que dans certains cas particuliers, Passer par l'assembleur peut booster les choses, mais dans 99% de ton programme, il faut le fuir.

Si tu regardes les sources de quakeIII, tu verra qu'il n'y en a aps des masses, pourtant c'est vachement bien optimisé (ca tourne sur un celeron 333MHz avec une TNT2 pour ceux qui auraient oublié). Il y a quand meme des fonction ou ca part dans le bas niveau, nottement la fameuse fonction qui calcule l'inver de la racine carrée, mais extrement peu d'assembleur.

Pourtant Carmack est pas un as du haut niveau, quake I a ete codé en grande partie en assembleur. Mais les cores ont beaucoup evolué depuis, les CPU aussi, et on touche pas beaucoup au bas niveau, entre ce que fait deja la STL, l'API 3d, le systeme d'exploitation, plus besoin de batailler avec les interruption de la carte son de nos jours.

Alors coller de l'assembleur dans quelques fonction tres tres utilisés, pourquoi pas, mais l'interret se justifie pas pour plus de 2% du code . . .

De facon generale, l'assembleur permet de gagner beaucoups moins de temps qu'un chagement d'algorhytme. la seconde otpion est donc souvent a privililegier.

On peut faire du tres bas niveau en C, souvent ca suffit.

[Kujara]

Deadalnix : Bien, bien, expliqué comme ça, je suis assez d'accord.

On peut faire du tres bas niveau en C, souvent ca suffit.

Malheureusement, pas toujours.
Et dans les cas où l'optimisation est le nerf de la guerre ( moteurs graphiques notemment), gagner ne serait-ce qu'1% de perfs, tu peux pas te permettre de passer a coté.

Bref, l'assembleur, c'est assez inutile pour le commun des mortels, j'avoue, mais ça peut quand même servir.

[Octopod]

Bah y'en a de l'idée reçu...

Et dans les cas où l'optimisation est le nerf de la guerre ( moteurs graphiques notemment), gagner ne serait-ce qu'1% de perfs, tu peux pas te permettre de passer a coté.

C'est complêtement faux. Je travail dans le domaine du jeu vidéo depuis plusieurs années et je n'ai jamais vu personne s'amuser à optimiser en assembleur quoique ce soit. Et surtout pas les routines servant à l'affichage (tu connais DirectX ?). Il en va de même pour la physique et l'IA (les deux autres bouffeurs de CPU d'un jeu). Mieux vaut utiliser intelligement les différents cores de ta machine (PC, XBOX ou PS3) et multithreader correctement pour gagner en perfs (et pas juste 1%).

Pour les algo bien complexes, laisser faire le compilateur en se disant qu'il optimisera tout seul, c'est pas seulement une preuve de stupidité crasse, c'est d'un anti-professionalisme aigu ....

Voila ton avis personnel. Je considère que c'est un peu le contraire, s'amuser à vouloir optimiser en assembleur (ton code) c'est oublier que les meilleures optimisations sont de haut niveau (ton algo). Après que ton compilo perde quelques cycles dans des instructions mal choisies, franchement on s'en fou.

Alexis.

[Kujara]

Je travail dans le domaine du jeu vidéo depuis plusieurs années et je n'ai jamais vu personne s'amuser à optimiser en assembleur quoique ce soit.

Ca tombe bien, moi aussi je bosse la dedans et j'en ai déja vu.Donc t'a du mal regarder ^^.

Les optims asm ça se retrouve principalement dans le fin fond du code des gros moteurs professionels( havok, source engine, etc), probablement enormement dans les drivers de carte graphique et autres choses du genre, dans DirectX / openGL justement, et plus facile a trouver pour le commun des mortels, dans certains moteurs 3D grand public( Ogre3D).

Je considère que c'est un peu le contraire, s'amuser à vouloir optimiser en assembleur (ton code) c'est oublier que les meilleures optimisations sont de haut niveau (ton algo).

Je n'oublie rien du tout, c'est juste que les optims haut niveau ont leur limites, et que quand tu a déja optimisé l'algo au maximum, tu est bien obligé de passer aux optims plus chaudes si tu veux gagner de la vitesse....

[bafman]

C'est complêtement faux. Je travail dans le domaine du jeu vidéo depuis plusieurs années et je n'ai jamais vu personne s'amuser à optimiser en assembleur quoique ce soit. Et surtout pas les routines servant à l'affichage

ha !
bah moi ca fait pas des années que j'y travail et pourtant j'en ai déjà vu pleins... C'est sans doute une question de philosophie de développement qui change selon les boites

[ac_wingless]

Fait attention a ce que tu dis ....

J'ai pas testé le compilo intel, mais le vc++ derniere version est très, mais alors très très loin d'optimiser parfaitement un algo de plus de 5 lignes.

J'ai gagné vitesse x 140 sur un algo de 40 lignes, en modifiant l'algo certes, mais si on considère juste l'implementation ( donc quelque chose que le compilo peut faire), je gagne x 10, quand même ... et ça c'est sans inline asm.

Je ne comprends pas tout à fait... vous avez changé un algorithme, et avez gagné un facteur 140 sans une ligne d'assembleur, et ça prouve qu'on peut programmer en assembleur 10x mieux qu'un compilateur? Au minimum c'est pas clair...
Parler de stupidité crasse et d'anti-professionnalisme aigu est de toute façon, me semble-t-il totalement déplacé dans ce forum, c'est pourquoi j'hésite à remettre les pieds dans ce qui semble tourner au troll. Cependant, justement, je pense qu'il serait bien qu'une voix un peu professionnelle permette aux éventuels candidats à l'assembleur pour 2008 d'avoir plusieurs sons de cloche.

En ce moment, je travaile sur un device driver d'une carte PCIe 16 lignes qui doit passer 22 Gb/s à une sorte de périphérique. Ca fait quand même beaucoup, d'autant plus que le signal externe doit être temps réel, ce qu'un PC sous Windows n'est pas. Pour corser les choses, la génération des données à transmettre est faite dans le GPU, qui certes est déjà sur le bus PCIe, mais je n'ai bien sûr pas accès aux FPGAs de mes 8800 GTX, donc je ne peux pas dialoguer directement avec ma carte PCIe. Je dois donc passer une quantité astronomique d'information dans les deux sens sur le bus, avec un télescopage massif en implémentation naïve. Nous avons tourné ce problème dans tous les sens, pour finalement arriver après 2 mois à une solution utilisant une compression / décompression pour ne pas exploser le bus. Résultat des courses: entre l'envoi des calculs sur DX10, le double passage sur PCIe, la compression / décompression, la bufferisation pour repasser en temps réel coté périphérique, PAS UNE LIGNE D'ASSEMBLEUR. Bien sûr, on a essayé. On a désassemblé quelques points critiques, on a essayé des variantes. Les gains étaient négatifs ou positifs, mais toujours minuscules, bien plus faibles qu'en utilisant Intel + VTune. Aujoud'hui, tout ne marche pas encore à la bonne vitesse, mais parmi les nombreuses pistes d'amélioration, nous avons exclu le recours à l'assembleur. Le seul endroit où on pense gagner significativement par l'assembleur, c'est justement sur un microcontroleur embarqué, mais lui est loin dêtre au taquet, et de toute façon n'est pas sur le chemin critique du passage d'info.

Je donnerai donc quelques pistes de réflexion personnelle, qui n'engagent que moi, mais qui s'appuie sur une expérience réelle, prouvée, et qui au moins tente de rester à jour (je n'y arrive pas toujours hélas).
- j'ai déjà donné dans le passé, massivement et à titre professionnel, dans la programmation assembleur. Je pratique, depuis presque autant d'années que l'age de certains posteurs. Jusqu'à il y a quelques années, j'aurais signé des deux mains la fameuse idée reçue "quand tu a déja optimisé l'algo au maximum, tu est bien obligé de passer aux optims plus chaudes si tu veux gagner de la vitesse". Aujourd'hui, j'ai changé d'avis. C'est pas exactement sur un coup de tête en écrivant un bout de post... c'est le résultat d'années d'évolution de mon travail, et surtout de son environnement.
- aujourd'hui, je suis époustouflé en désassemblant certains morceaux venant du compilateur Intel. Le code généré semble curieux et contourné à première vue, mais il recouvre des ruses qu'on peut comprendre une par une, certes, mais l'avantage du compilateur est qu'il peut intégrer la totalité des concepts en jeu, et en tirer une synthèse exacte. Par exemple les tous derniers compilateurs sont capables de re-générer du code après analyse de l'éxécution sur jeu de données fournis par l'utilisateur. Ils peuvent en particulier modifier le code pour ré-allouer les registres selon les appels inter-procédure qui ont effectivement lieu d'un point de vue statistique (rappel: la quasi-totalité de ce qui agit dans les processeurs récent comme "registre" n'est même pas accessibles en assembleur!! on en est réduit à du pifométrage sur comportement du cache, alors que l'optimiseur a une description fonctinnelle détaillée couplée à des échantillons couvrant des milliards d'éxécutions). J'en passe et des bien meilleurs (des 1992, gcc était capable avec un addon d'envisager toutes les solutions valides pour tout groupe de 5 mouvements, d'éxécuter toutes les variantes et de sélectionner la meilleure. Aujourd'hui, cela s'étend non plus aux seuls mouvements dans les registres, mais sur les caches, les branchements, et la charge en utilisation réelle - pour Intel en tout cas). Conclusion: sur le code haut niveau, les problèmes éventuels sont d'abord algorithmiques. Sur un code suffisamment bas niveau, si un humain fait mieux que l'optimiseur, c'est un bug de l'optimiseur. J'ai bien lu au dessus que certains prétendent y parvenir, j'en doute fortement, restons en là.
- dans tous les cas, on peut raisonner au niveau du processeur en C++. Quant on voit un paté VTune sur son propre code (rare), c'est une très bonne nouvelle car on peut tenir compte facilement des problèmes de cache et autres pagination en changeant les mouvements de données, et non pas les instructions assembleur. On peut considérer cette technique à la limite comme de la programmation "consciente du microprocesseur", mais ça reste du C++ pur et dur, pas de l'assembleur.
- les gisements de performance sont aujourd'hui dans la gestion du multicoeur, des mouvements de mémoire, des flux sur les différents bus et caches, et l'utilisation des coprocesseurs (GPU, et bientôt autres). Certes, quelqu'un qui est familier avec l'assembleur va sans doute être un peu mieux équippé pour gérer ces problèmes. A titre professionnel, j'ai constaté qu'on fait maintenant appel à moi pour typiquement ce genre d'optimisaton, et non plus pour l'assembleur. La compétence "assembleur", rendue inutile par l'automatisation due aux optimiseurs ultra-performants, change de forme et s'adapte au matériel récent: il s'agit de comprendre les implications en termes de performance des différents parties du matériel, et non plus seulement du microprocesseur lui-même.
- utiliser l'assembleur fait un pari sur la NON variation du matériel, au cours du temps, mais aussi sur un parc d'ordinateurs à un moment donné. Il est bien plus sûr aujourd'hui, lors de l'écriture d'un device driver même orienté performance, de faire appel aux fonctions système. D'abord, c'est impossible de faire certaines choses sous Vista au niveau d'un programme non-kernel. Ensuite, même sous kernel, Windows a de nombreux "routages" qui s'adaptent au type du processeur qui tourne effectivement, voire au nombre de coeurs, pour éxécuter des variantes localement idéales. Tout instruction en assembleur détruit cette optimisation.
- enfin, pour sortir du monde Windows, faut-il rappeller que certains microprocesseurs sortent aujourd'hui SANS assembleur? Certes, il s'agit pour l'instant de processeurs spécialisés, à jeu d'instruction compliqué comportant des millions ou milliards d'instructions toutes quasi identiques. Certes, le compilateur livré connait cet "assembleur" caché... mais l'humain est désormais en dehors de la boucle. De même que les processeurs d'aujoud'hui sont 100% conçus par des compilateurs de silicium, et non des titouillages savants de portes logiques par des électroniciens, de même l'assembleur est condamné à disparaître.

Je terminerais sur cette question: quelqu'un a-t-il livré du code professionnel, en 2007, utilisant de l'assembleur sur autre chose que des processeurs embarqués?

Moi non, et c'est la première fois depuis de nombreuses années.

Et ce n'est pas la dernière fois.

[deadalnix]

On est donc quasiment d'accord. OIn disiat justement que ca se jusitifie pour 1% du code si on y tiens vraiment, et que les cores sont maintenant fait pour executer du code compilé et non de l'asm ecris a la main.

A noter qu'on obtiens des gains plus important en optimisation de type bas niveau ecrite en C voir en C++. Je pense au dual loop algorhytme, qui optimise la predicition de branchement, et qui peut etre mis en place en C/C++ .

L'idee est de remplacer une boucle par deux boucles imbriquées incrementant le meme compteur. La boucle imbriqué ne contient aucun autre test que le fait de boucler ou non, et ce test doit etre vrai dans la majeur partie des cas.

On obtient un gain de 20% par exemple par rapport a la fonction de la lib standard de C qui compte le nombre de fois qu'un caractere apparait dans un chaine.

Cela dit, faut pas etre si tranchant, car de nombreux projets tres pros contiennent des lignes d'assembleurs sur des points critiques.

[bafman]

à l'heure actuelle, le principal interet de descendre en ASM n'est pas l'optimisation algorithmique, c'est principalement l'optim calculatoire en se basant sur les instruction vectorielles du type SSE et autre qui permettent de faire plusieurs calculs par cycle. Et c'est très utile en 3D ou, par un heureux hasard , on utilise justement pleins de données stockées sous forme vectorielle. Or, l'optimisation de calculs en utilisant des instruction vectorielles, les compilo ne savent pas faire...

[LeGreg]

Il faut aussi tenir compte que assembler = facile (donc rapide), compiler = dur (donc relativement lent meme en just in time).
Une des utilités de l'assembleur a donc été dans plusieurs programmes que je connais de coder des inner loops de façon imbattable avec un assembleur à l'exécution (certes ce n'est pas courant pour un programmeur lambda mais usage suffisamment notable surtout que ça puisse vous intéresser en temps que simple "utilisateur").

Il semblerait globalement que pour tout ce qui est tight loop, memcopy, swizzleur en SSE, l'assembleur soit encore utile. Quant au compilateur intel, on ne peut pas l'utiliser dans ma boite pour x raisons.

Pour la difficulté de maintenance, je dirais que l'assembleur que j'ai vu utilisé n'était pas particulièrement dur à maintenir, sans doute moins que le code C++ qui a tendance à se faire "désoptimiser" avec le temps. Tout est question de perspective..

LeGreg
ps : j'ajouterai que dans mon domaine cpu-limited is a curse.

[PierroElMito]

à l'heure actuelle, le principal interet de descendre en ASM n'est pas l'optimisation algorithmique, c'est principalement l'optim calculatoire en se basant sur les instruction vectorielles du type SSE et autre qui permettent de faire plusieurs calculs par cycle. Et c'est très utile en 3D ou, par un heureux hasard , on utilise justement pleins de données stockées sous forme vectorielle. Or, l'optimisation de calculs en utilisant des instruction vectorielles, les compilo ne savent pas faire...

si c'est juste pour faire des appels aux fonctions SSE, tu peux utiliser les instructions sans passer par de l'assembleur avec les "intrinsics" du compilateur. c'est un peu moins roots...