Bonjour, je suis à la recherche d'un éventuel convertisseur de langage C en assembleur, pourriez-vous m'aider, me donner des infos là dessus ? Merci d'avance !!!
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
C en assembleur ? est-ce que ça existe ?
Bonjour, je suis à la recherche d'un éventuel convertisseur de langage C en assembleur, pourriez-vous m'aider, me donner des infos là dessus ? Merci d'avance !!!
Cela s'appelle un "compilateur".
Oui. Ton compilateur a sans doute une option qui permet de garder le ficher source assembleur. (Je crois qu'avec gcc, c'est -S)Envoyé par John Davis
C'est une question pour le forum http://www.developpez.net/forums/forumdisplay.php?f=65
Avec gcc, c'est l'option -S, ca te créé un fichier assembleur avec la syntaxe AT&T si je me souviens !
Et bienvenue sur les forums de developpez.com
-masm=intel avec des versions suffisemment récentes (au moins depuis la 3.2 -- et vu le rapport entre la 3.2 et la 3.1 ça m'étonnerait que ce ne soit pas dans la 3.1).Avec gcc, c'est l'option -S, ca te créé un fichier assembleur avec la syntaxe AT&T si je me souviens !
Et bienvenue sur les forums de developpez.com
Je prend note, c'est toujours bon à savoir, merci pour la précision
Oui, c'est exact : les options -S et -masm=intel engendrent bien un fichier assembleur .s du même nom que le fichier source : je le sais car je les utilise très fréquemment.
Quelques petites remarques : si tu veux retrouver tes chatons dans le code assembleur engendré par le compilateur, je ne saurais trop te recommander de compiler sans optimisations, donc avec la commande typique : "gcc -masm=intel -S -Wall nom_de_fichier.c", et ce pour une raison très simple : le code engendré par gcc avec l'option -O3 (optimisations génériques maximales) est extrêmement difficile à lire.
Mieux vaut au début compiler sans optimisations, au moins avec les versions 3.3.1 et antérieurs de gcc, car il produit alors un code assembleur, et gcc a été fait pour celà, très proche du code C... donc parfaitement lisible.
L'exercice inverse peut être très amusant, enfin pour quelqu'un qui, comme moi, s'amuse comme un fou lorsqu'il programme en essembleur : écrire des sous-routines, voire des fonctions, an assembleur et les utiliser en C. Il faut pour celà "apprendre", bien que le mot soit mal approprié, le standard des appels de fonctions C, trivial ou presque si on a l'habitude d'organiser son mode de pensée dans ce langage.
Tu pourras ainsi comparer les temps d'exécution entre une fonction écrite en C et compilée avec toutes les optimisations du compilateur (du moment qu'elles ne rentrent pas en conflit) et une fonction écrite directement en assembleur : tu te rendras vite compte que le code engendré par un humain est aujourd'hui dans la plupart des cas, mais pas tous tout de même, sous-optimal comparé à celui produit par le compilateur.
On apprend ainsi à regarder ces drôles de bestioles que sont les compilateurs d'une autre façon !
Ca n'a rien à voir. l'ABI (Application Binary Interface) est propre à chaque compilateur. Elle est certe documentée, mais n'est absolument pas standardisée. Ce qui se passe en C sous DOS/Windows n'a rien à voir avec ce qui se passe en 68k ou en PowerPC...
Il faut tout réapprendre à chaque nouvelle cible.
Je parle uniquement de ce que je connais.
Sous IA-32, il semblerait qu'il y ait au moins une interface commune sur laquelle les développeurs de compilateurs semblent s'entendre : elle est de plus quasiment identique entre le monde Unix, Linux et Windows. Certes, il est très probable que de petits différences existent selon le compilateur, mais, d'après ce que je sais et ce que j'ai pu expérimenter, il est tout de même nécessaire de se mettre d'accord au moins sur quelques points... ou sinon il y aurait des problèmes à faire tourner des programmes compilés avec des compilateuirs différents sur la même machine.
Là encore, je parle de ce que sais d'après la documentation fournie avec NASM et autres sources.
Les différences que je connais de ce côté-là concernent les paramètres des procédures (dépilés par le programme appelant sous Unix/Linux et par le programme appelé sous Windows), ainsi que le système d'utilisation de l'instruction INT (paramètres passés par la pile sous BSD, par registres sous Linux, en général).
Je suis d'accord, on ne peut comparer que pour un même type de processeur, et parfois de système.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager