Discussion :

[orichimaru]

voila je suis pas un pro de l'assembleur du tout et je voulais savoir quelles operations ( je parle d'addition multiplication ... ) on peut effectuer a l'aide de la pile et de quelle maniere, cad par exemple est ce qu'on peut mettre 2 elements sur le haut de la pile et à laide d'une commande particuliere les additionner, sans passer par les registres et add ou mul

[Nico*3-3]

Eh bien désolé de te décevoir mais les seules façon de multiplier un nombre avec un autre (avec l'integer unit) sont mul et imul, qui se servent forcément d'au moins un registre pour fonctionner, puisqu'on ne peut pas éxecuter une instruction avec plusieurs opérandes mémoires...

Enfin, je t'ai menti, il y a une autre façon de faire une multiplication : tu fais une boucle avec des add
Non je plaisante...

Salut !

Blustuff : Je suis arrivé le premier !

[Blustuff]

Pour le x86, toutes les opérations arithmétiques passent par au moins un registre. Donc, l'une des opérandes doit être sortie de la pile :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
pop eax
add [esp], eax

Le FPU utilise quant à lui un système de pile, mais interne au processeur.

[orichimaru]

a uééé blustuff c pas mal du tout, et si je fais add eax,[esp] le resultat sera bien dans la pile hein ?
et merci a tout les 2 !!

[Nico*3-3]

Raté ! :o
Quand tu fais un opération, le résultat sera placé dans la destination parmi les opérandes de l'instruction (c'est presque toujours la première opérande d'une instruction, la seconde étant la source)
Dans ce cas (add eax, [esp]), eax est la destination, le résultat sera donc placé dans eax.
Mais il y a une façon de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
pop    eax
add    eax, [esp]
push   eax

C'est un exemple justement pour additionner deux nombres sur la pile entre eux :
- celui à [esp] avant le début de l'opération
+
- celui à [esp+4] avant le début de l'opération
Et en stockant le résultat à [esp] avant le début de l'opération...

De cette façon le résulat finit sur la pile, mais pour l'opération elle-même, il est impossible d'utiliser plus d'une opérande mémoire, il faut donc faire des "transferts".

[Nico*3-3]

Pourquoi vouloir s'embêter à additionner des valeurs sur la pile alors qu'on peut les avoir à un autre endroit ?

[orichimaru]

ben en fait c packe je suis en train de coder un evalueteur d'expression mathematique , et dans la cadre de l'ecriture postfixe, ca m'aurait arrangé de pouvoir effectuer des operations comme ca : on pousse les 2 operandes et en dernier l'operateur et on evalue , mais bon je vais essayer de faire ca moi meme

[orichimaru]

j'ai une autre question, peut on, comment dire changer le code du prgm compilé ?
cad je m'explique : dans mon cas je veux effecteuer une operation sur 2 operandes, alors je pensais qu'au lieu de traiter chaque cas differement, traiter le tout dans une meme fonction cad une fonction qui devrait ressembler a ca :

en entrée tout sur la pile dans cet odre : operande1, operande2, code_de_l'operation

pop [adresse de la comande a changer]
pop eax
commande dont on connait l'adresse ds le prg et qu'on peut changer [esp],eax
ret

[sdx]

Oui, tu peut modifier le code éxecutable de ton prgm pendant l'execution, mais c'est plutôt déconseillé !! y a rien de mieux pour tout faire planter !!

si tu y tient vraiment, il suffit de modifier ce qui se trouve dans [CS:etiquette], avec etiquette n'importe quelle étiquette dans ton source.

mais il doit surement y avoir mieux que ça ... par exemple, passe une adresse de fonction à apeller au lieu d'un code d'operation. Tu pousse l'adresse (offset) d'une procédure qui fait ton addition, ta soustraction ... comme ça, ton code est léger et les fonction de calcul peuvent facilement prendre en charge les dépassement de capacité sans alourdir le code

je sais pas si je suis très clair quand je parle, mais qq d'autre peut sûrement proposer une autres technique

sdx

PS:

[orichimaru]

ca se tient, et ca me parait bien moins contraingant, merci pour le tuyau sdx

[Blustuff]

Il faut définitibement écarter la possibilité du Self-Modifying Code. Cette solution a d'ailleurs beaucoup de chances d'échouer : Si vous modifiez une partie de code qui a déjà été chargée dans le cache de code du processeur, cela ne fonctionnera pas. Et dans votre première solution, il y a énormément de chances que ce soit le cas.

La solution de SDX est la bonne. Il est par contre peut être plus efficace de procéder par sauts et non par appels de fonctions, mais je n'en suis pas sûr. Peut être faudrait il tester.