Version imprimable
Salut !
J'essai le fameux
mais le mot clé "asm" n'est pas reconnu par mon compilo (visual studio 2005).Code:
2
3
4
1-Comment fait on ? Faut il un header pariculier ?
2-Si met un mov AX, maVariableC++ cela va t il marcher ? sinon comment fait on pour utliser des variables C++ avec du code asm x86 ?
__asm peut etre.
le mot clé __asm n'est pas supporté sur les plate formes amd64.
visual recommande d'utiliser les "intrinsics" a la place.
Merci screetch ! ça marche !
mais comment on peut faire pour que ce soit portable ?
c'est quoi les intrinsics ?
Salut, et bienvenue sur le forum.
Déjà, je me poserais réellement la question de savoir s'il y a réellement un avantage à insérer du code assembleur dans ton projet.
Je ne nie absolument pas qu'il y ait des cas dans lesquels c'est intéressant, mais j'ai honnêtement l'impression que cela revient très souvent à chercher la difficulté là où il y avait parfaitement moyen de faire beaucoup plus simple.
Dans bien des cas, le compilateur te fournira un code assembleur sans doute bien plus efficace que tout ce que tu pourrait écrire toi même.
Oui mais j'ai toujours entendu dire que l'assembleur s'exécutait plus vite que le C ou le C++, ce n'est pas le cas ?
il n'y a aucune portabilité du code asm. les intrinsics sont comme des fonctions C (en tous cas la meme syntaxe) mais sont en fait equivalentes aux instructions assembleur. il est devenu desormais impossible d'inserer du code asm dans ton code c++.
La seule raison valable pour inserer du code asm est d'utiliser des instructions speciales que le compilateur ne connait pas ou n'utilise pas; un exemple est le BREAKPOINT; pour faire un breakpoint sous windows on peut utiliser l'instruction asm "int 3" (soit en gros declenche l'interruption numero 3). mais va faire ca en C++! ^^
les autres instructions utiles sont les instructions MMX ou SSE qui ne sont toujours pas comprises par les compilos modernes; dans le cas d'un code que l'on souhaite paralleliser (au niveau du proc, pas au niveau des threads) l'assembleur reste obligatoire.
On pourrait aussi parler de instructions asm interlockées qui permettent d'avoir de l'atomicité.
pour palier a ce probleme, on a desormais les intrinsics; ce sont des fausses fonctions C qui seront remplacées a la compilation par une sequence secrete d'instructions ASM; ces intrinsics existent pour SSE, MMX, les interlocked, la fonction qui declenche un breakpoint. elle est pas belle la vie ?
voir le fichier intrin.h pour la liste des intrinsics connus par ton compilateur. hautement peu portable mais plus que l'assembleur. il y a aussi xmmintrin et emmintrin.h, et mmintrin.h
pas a cette echelle. n'espere pas ecrire du code plus performant que ton compilateur, ou alors ecrit une grosse portion en assembleur (ce qui signifie que tu peux optimiser le passage de parametre car tu sais ce que tu fais) mais bienvenue dans le monde de l'instabilitéCitation:
Envoyé par blueLight
Donc si j'ai bien compris il n'y a aucun intérêt à insérer de l'asm dans du C++ ?
Dans ce cas, quelle utilisation fait on de l'asm dans les jeux vidéo ?
on en fait pas. pas a ma connaissance ^^
lorsqu on fait du bas niveau dans les jeux videos, on fait surtout justement du SSE/MMX. on utilise donc un peu les intrinsics. et c'est seulement a quelques endroits tres tres localisés
J'aurais presque envie de dire que ceux qui disent cela n'ont pas compris grand chose:Citation:
Envoyé par blueLight
Un processeur ne comprend qu'une seule chose: le binaire, et, sur l'ensemble des possibilités dont il dispose, et selon un schéma pré déterminé, il reconnait un certain nombre de valeurs comme étant des instructions.
Comme il n'était pas évident de retenir ce à quoi correspond une instruction prise au hasard de l'ordre de 01011100, les informaticiens ont réfléchis à une représentation plus "compacte" et décidé d'utiliser l'hexadécimal.
L'instruction précédente est alors devenue 0x5C.
Mais cela restait relativement abstrait, et on est donc passé à des mnémoniques, de manière à se rappeler plus facilement que adda signifie tout simplement "additionne (la valeur qui suit) à la valeur qui se trouve dans le registre a".
L'assembleur, ce n'est que cela ;)
C'était déjà mieux, mais pas "génial" pour autant, car si on commence à comprendre ce que signifient les instructions, les valeurs à fournir pour permettre à l'instruction de travailler sont, au choix:
(du moins, si on étant la réflexion à toutes les instructions ;))
- rien
- une valeur connue
- l'adresse à laquelle retrouver la valeur à utiliser
En plus, il reste difficile de déterminer si une valeur de 0x20 correspond à la valeur numérique ou au caractère "espace".
On a donc décidé de créer des langages "proches du langage parlé", qui ont pris la forme de langages ancestraux tels que le fortran, l'Ada, le COBOL, le Basic, et tant d'autres.
L'idée est relativement simple: on demande à un outil (le compilateur ou l'interpréteur) de parcourir le code et de le transformer, selon certaines règles, en code binaire utilisable.
Charge est laissée à cet outil de déterminer quelle commande il doit utiliser dans le contexte qui lui est donné.
Par la suite, on a décidé que l'on voulait pouvoir se rapprocher encore un peu de "ce qui se fait dans la nature", en ayant la possibilité d'inter-agir avec les éléments (leur envoyer des messages), sans pour autant avoir besoin de savoir comment l'élément gère ce message (la manière dont digère un rhinocéros n'intéresse sans doute pas grand monde :D)
Et le concept de langage "orienté objet" est né.
Voilà de manière très résumée et extrêmement approximative ce qui a conduit à délaisser l'assembleur au profit des autres langages ;)
Mais il ne faut pas oublier que ma nièce qui a six ans est bien plus intelligente que n'importe quel ordinateur: elle a son propre libre arbitre.
Un ordinateur (et donc le compilateur ou l'interpréteur) se contente de réagir de la manière dont on lui a dit de le faire. Et les règles qui lui sont données sont suffisemment précises pour avoir, à l'heure actuelle, la quasi certitude que le code exécutable qu'un compilateur fournira sera "le plus efficace possible" par rapport aux informations de contexte qu'il aura pu déterminer.
Il est même fortement probable que tu n'arrive jamais à fournir par toi même un code exécutable plus efficace que celui qui aura été déterminé par le compilateur ou l'interpréteur.
Bien sûr, comme l'a fait remarquer screetch, certaines "nouvelles" parties du jeu d'instructions des derniers processeurs sont (encore) mal gérées, mais cela reste vraiment anecdotique ;)
Pour répondre à ta dernière question, on pourrait presque dire que la réponse est "jamais", à moins de savoir pertinemment que le jeu video n'utilisera jamais qu'un seul processeur bien particulier, et dans le seul cas où des benchmarks montrent un réel avantage à le faire.
c'était vrai il y a quelques temps notamment de celui de Michael Abrash et ses livres sur l'optimisation du code.Citation:
Envoyé par blueLight
Mais maintenant comme il a été dit les compilateurs sont assez optimisés et pas dit que tu obtiennes des performances accrues avec du code pur assembleur..
Si tu veux programmer bas-niveau il y a des langages spécifiques pour les cartes vidéos comme HLSL il me semble
Et bien disons dans le cas de la programmation sur console ? là où le(s) processeurs ne change pas d'un utilisateur a l'autre, quand est ce utilisé ? (si ça l'est)
ce n'est pas vraiment plus utilisé. la plupart des jeux sont portables (e.g. Playstation 3 / XBox 360 / voire meme PC des fois) et le code assembleur serait non portable.
on utilise sur les consoles les intrinsics egalement, car ils ont globalement la meme utilité sur console que sur PC : se servir des instructions SSE et MMX (qui ne sont pas sur console, mais on trouve des equivalents)
ok mince :-(
Ben merci sinon les gars pour vos réponses !
A ma connaissance la programmation en assembleur n'est utilisé que sur des cartes à faible mémoire embarqué (du genre 4 Ko).
Encore une fois, étant donné qu'on peut définir une priorité à la taille dans les options du projet, je sais pas si ça sert à grand chose.
Pour synthétiser, je dirai que l'assembleur est un langage "machine", complètement binaire. On a créé des compilateurs pour générer ce code "barbare" à notre place avec des langages plus appropriés.
Programmer en assembleur, sans un but précis, c'est revenir au temps de la préhistoire. Alors qu'aux jours d'aujourd'hui, on préfère la réutilisabilité ! ;)
ok merci ! :D