Salut à tous. J'aurais une question.
 
Disons qu'on code qqchose en C. Quand on le compile, ca le 'sort' en language assembleur, c'est bien ca ?
 
Meme chose en VB par exemple, dés qu'on compile le soft, ca donne un truc en language assembleur ?
 
Ainsi de suite ?
 
Et ce language assembleur pourra etre décodé puis traité par les unités d'executions du microprocesseur, c'est ok jusque là ?
 
Merci de confirmer/corriger ou montrer que ce que je viens de dire est complétement faux.

Salut tout seul
 

J'aurais une réponse
 

Oui
 

Non, ça donne du p-code interprété par les runtimes vb ou par le framework .net pour VB .NET
 

Non. Java, Python, C#, etc... ne sont pas compilés mais interprétés
 

Assembleur != langage machine.
Assembleur = langage binaire de haut niveau. Seul les opcodes finaux en binaire seront éxécutés par le CPU
 

C'est fait.

C --> asm --> machine --> décodé et interpreté par le microprocesseur.
 
là c'est ok ?

ça dépend...
certains compilateurs C passent directement du code C au code machine sans passer par la case Asm

j'ai jamais vu ça, c'est jsute que ce sont des front-end qui se chargent de tout. l'option -S de gcc permet de s'arréter  apresla génération du code assembleur. -save-temps (ou quelque chose approchant), conservent tous les ficheirs utilisés (préprocesseur, asm, objet, etc). -pipe permet à gcc de faire communiquer les differentes unités de compilation par pipe plutot que par ficheir temporaires

hum ... ca me fait un peu grincer des dents cette définition.
Langage binaire, est-ce que ça veut dire quelque chose ?
Système binaire oui, langage ... langage machine est un terme plus approprié.
langage d'assemblage = langage de bas niveau permettant d'utiliser des mnémoniques représentant les instructions du processeur et qui est directement traduit en langage machine par un assembleur.
 

 
Le processeur n'interprète rien, il exécute.
Pour VB, c'était pas de chance car c'est une exception. Sinon, pour les langages compilés, on retrouve à peu près ce schémas.
 
Une fois que tu as un compilateur C performant (qui optimise bien), t'as pas envie de tout refaire a chaque compilo. Donc, on trouve même souvent (gcc par exemple) :
Langage quelconque (C++, ADA, FORTRAN, ...) --> C --> asm --> machine.

Dans l'absolu, quand on a un langage d'un certain niveau, on peut toujours écrire un traducteur (compilateur ou interpréteur) pour un processeur abstrait qui comprend un langage de plus bas niveau.
Ainsi quand on écrit un traducteur, par exemple, C++ vers C, en fait on fait comme si on disposait d'un processeur abstrait qui comprend le C. Peu importe qu'en fait, il faille ensuite refaire une traduction pour transformer les instructions de ce langage de moins haut-niveau dans un autre langage d'encore moins haut-niveau.
 
Ce qui fait qu'ainsi, on se retrouve à disposer d'un processeur abstrait de très haut-niveau, qui est fait de plusieurs couches qui correspondent à chacun des niveaux de traduction. Typiquement : C++ -> C -> assembleur -> microcode processeur.
Hé oui, sur la plupart des processeurs actuels, ce qu'on appelle le "langage machine", qui est une traduction binaire du langage assembleur, n'est pas le langage "natif" du processeur, mais c'est déjà un langage de haut-niveau, qui est traduit à la volée par le processeur dans son propre langage de plus bas-niveau qui est le micro-code.