Question simple mais piège

Voila une question qui m'a été posée et j'aimerais la partager avec vous.
Les compilateurs des langages produisent un fichier binaire. Comment ces informations arrivent jusqu'au microprocesseur?
Eh oui, un curieux a osé posé cette question. Il a le droit!
Ma réponse était très brève:
Le fichier produit par le compilateur est pris en charge par le système d'exploitation qui a déjà préparé le terrain pour distribuer les signaux binaires aux différentes cartes et donc au processeur.

On a riposté pour me dire: Mais alors que se passe t- il si le langageA est écrit en un autre langageB?
Ma réponse est: HUUUM, ou bien le compilateur se charge de toutes les traductions (super compilateur) jusqu'aux codes binaires, ou bien le compilateur A traduit les infos en un langageB, puis le compilteur B traduit en codes binaires.

Réagissez, si vous avez des choses à rajouter pour rendre les réponses plus claires; je n'ai pas pu faire mieux.

Que veux-tu dire par "le langageA est écrit en un autre langageB" ?

Dans Java, il y a du C par exemple.

Langages intermédiaires

Certains langages appartiennent en quelque sorte aux deux catégories (LISP, Java, Python, ..) car le programme écrit avec ces langages peut dans certaines conditions subir une phase de compilation intermédiaire vers un fichier écrit dans un langage qui n'est pas intelligible (donc différent du fichier source) et non exécutable (nécessité d'un interpréteur). Les applets Java, petits programmes insérés parfois dans les pages Web, sont des fichiers qui sont compilés mais que l'on ne peut exécuter qu'à partir d'un navigateur internet (ce sont des fichiers dont l'extension est .class).

Citation:

---

Dans Java, il y a du C

---

Développe. Parles-tu du fait que la JVM soit implémentée en C, ou du fait qu'en java on puisse appeler des bibliothèques C (via JNI) ?

Non je parle de la JVM.
Qu'en penses tu de la réponse fournie?

Aucune des deux réponses n'est bonne.

Au moment où tu télécharges la JVM sur un PC 32 bit, elle n'est plus en C ou un autre langage de haut niveau: Elle est en codes binaires pour x86, puisqu'elle a déjà été compilée par Sun.
Pour le bydecode java qu'on y injecte, deux méthodes:

• Ancienne méthode, l'interprétation: Les octets du bytecode sont lus par la JVM, qui fait un gros switch() dessus et agit.
• Méthode actuelle, compilation just-in-time: La version x86 de la JVM traduit le bytecode java pour toute la méthode (voire une échelle plus grande, genre toute la classe) en codes binaires pour x86, puis "appelle" ce code.

Je dois revoir ma copie. Mais avant, j'aimerais avoir quelques confirmations.
La question de départ, si je la rectifie, doit mentionner que le fichier binaire produit (ou bytecode) ne passent pas nécessairement par un traitement système (c'est le cas de la JVM).
Je suis très surpris par le fait que les signaux binaires (de contrôle,codage...) partent directement aux cartes. Le noyau du système doit tout de même les aiguiller ne serait ce que pour la gestion des bus (contrôle, adresses, données en ne parlant pas des interruptions). Je vais peut être très loin dans le raisonnement. Je n'essaye que faire des connexions sans trop m'avancer. D'ailleurs c'est pour cette raison que mes réponses sont des fois brèves. Je me trompe peut être.
pour le langage A écrit en langage B, il y a quand même une étape intérmédiaire de compilation; je ne parle plus du cas de la JVM (j'ai donné le mauvais exemple).

Citation:

---

Au moment où tu télécharges la JVM sur un PC 32 bit, elle n'est plus en C ou un autre langage de haut niveau: Elle est en codes binaires pour x86, puisqu'elle a déjà été compilée par Sun.

---

Au début il y avait du c . Sun a compilé puis le fichier binaire est prêt.
Il y a eu tout de même compilation.
J'essaye de comprendre

Le code binaire ne passe pas directement du disque au microprocesseur: Il passe du disque à la mémoire interne du contrôleur de disque, puis de la mémoire interne du contrôleur de disque à la mémoire générale de l'ordinateur.

Ce que fait l'OS, c'est allouer la mémoire nécessaire, ordonner le chargement du programme vers telle adresse, fait quelques corrections (comme le mapping des appels de fonctions vers des DLLs), puis (je simplifie, car avec les histoires de processus c'est un poil plus compliqué) fait un bète appel de fonction sur le début du programme (son "point d'entrée").

Et l'appel de fonction, c'est quoi? C'est une bète suite de codes binaires qui dit "tu copies l'adresse actuelle d'exécution (registre 'IP' d'un x86, signifiant 'Instruction Pointer') à telle autre adresse, puis met ce que je te dis dans l'adresse d'exécution"

Donc, l'OS lui-même ne gère que les codes binaires d'instruction pour le processeur. Si le programme à exécuter est en fait un script écrit dans un langage interprété, le code binaire est celui de l'interpréteur, et l'OS ne voit jamais le script lui-même comme un programme.

Merci pour la clarté du message.
Si j'ai bien compris, l'os place dans le registre IP du processeur l'adresse de l'instruction à exécuter et évidement par incrémentation, on passe d'une instruction à une autre . L'os est également présent pendant l'exécution pour gérer les processus. Je ne parle pas des interruptions puisqu'elle peuvent être réalisées en hard.
L'os est en quelque sorte un convoyeur! mais également un contrôleur (bus d'adresse + bus de contrôle et donc automatiquement par le biais du codage le bus de données).

Les choses ont été mises à leurs places.
En tout cas, merci à toi.

En clair, quand un fichier binaire exécutable est chargé par l'OS, celui-ci se moque de (et ne peut pas) savoir dans quel langage était le programme avant compilation. Tout ce qu'il voit, c'est un fichier avec un en-tête prévu pour l'OS (avec entre autre, une table d'importation de fonctions de DLLs) et des codes pour le processeur (dans le cas d'un PC 32 bits, les codes x86).

Évidement, dans le fichier binaire il n'y a pas de trace sur le langage de départ puisque tous les langages convergent vers le même code exécutable.
En fait, je vois tout cela comme une grande réaction en chaine. des signaux attaquent des composants qui créent d'autres signaux pour attaquer d'autres composants ect.... (Merci au codage et surtout un grand merci aux portes logiques ...).

Je trouve qu'actuellement les développeurs ne s'aventurent pas à aller voir ce qui se passent au bas niveau. C'est vraiment dommage. cela pourrait éviter bien de problèmes , par anticipation, lors du développement. Enfin bref.

Si tu as deux secondes à nous consacrer :
je n'ai pas encore développé en d'autres langages objet que JAVA. Les choses se passent il de la même manière après compilation dans les autres langages?

Personnellement, je me rappelle vaguement avoir vu une fois comment marchait un registre avec des bascules JK, mais je descend rarement en dessous du niveau du registre, y compris dans un processeur virtuel sur lequel je bosse à mes heures perdues.

Pour ton autre question, ça dépend des langages:

• Le langage C++ est entièrement compilé, et il me semble que c'est le cas aussi pour Fortran et Delphi.
• L'ancien Visual Basic (VB6) était du semi-interprété sans JIT (comme l'ancien java).
• Les langages destinés au Framework .Net se comportent comme le java moderne:
  Chaque langage (C#, C++/CLI, F#, Delphi.Net, VB.Net, J#) est compilé en bytecode CIL (différent du bytecode java, et apparemment d'un niveau un peu plus élevé vu qu'il était dès le début prévu pour du JIT), et le programme est JIT-compilé par le Common Language Runtime (CLR), qui remplit le même rôle que la JVM.
• Il existe aujourd'hui de nombreux langages de script orientés objet. Il me semble que la plupart sont toujours interprétés (comme javascript), mais certains sont semi-interprétés comme VB6.

Merci, tout est clair.
Quand je disais que les développeurs doivent de temps en temps descendre un peu au bas niveau, c'est par ce qu'il arrive qu'ils aient besoin de capter des informations d'une carte géré par microprocesseur comme par exemple des applications qui reposent sur l'acquisition des données provenant d'un capteur ou d'un microcontroleur. En fait, pour moi, ils doivent toucher ne serait ce qu'un peu en informatique industriel et donc comme je disais le bas niveau.
certes, tous les développeurs ne vont pas avoir affaire à acquérir des signaux! Mais bon, je me trompe peut être.
En tout cas un grand merci à toi; j'ai appris beaucoup de choses et d'autres personnes lisant cette discussion en témoigneront certainement.

Avec un peu de recul, il y a un truc que je n'ai pas compris :

Citation:

---

Méthode actuelle, compilation just-in-time: La version x86 de la JVM traduit le bytecode java pour toute la méthode (voire une échelle plus grande, genre toute la classe) en codes binaires pour x86, puis "appelle" ce code.

---

Quand tu as dis :

Citation:

---

La version x86 de la JVM traduit le bytecode java pour toute la méthode (voire une échelle plus grande, genre toute la classe

---

De quelle méthode s'agit-il? et de quelle classe s'agit il?
Tu as raisonné "objet", et il y a un truc que j'ai zappé.
Pourrais tu éclairer mes lanternes.
Bien à toi

Je parlais de la méthode appelée.
Imagine par exemple ceci:

Code:

---

1 2 3 4 5 6 7

class Toto { public void hello() { System.out.println("salut"); } }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class Tata { public static void Main(string[] args) { Toto t = new Toto(); //1 t.hello(); //2   Toto t2 = new Toto(); //3 t.hello(); //4 } }

---

Tu compiles, tu obtiens Toto.class et Tata.class, qui contiennent tous les deux du bytecode Java, puis tu exécutes "java Tata" sur un PC 32 bits (donc, avec une JVM version x86).

Là-dedans, en JIT, je vois deux scénarios possibles lors des appels à Toto (je ne vais pas parler ici de l'appel ni de la compilation JIT de Tata, car c'est peut-être plus compliqué pour le main, donc je prends un exemple "typique" à la place) :

• Compilation JIT "par classe": Au moment du "new Toto" ligne "1", la JVM fait la compilation JIT de la classe Toto, traduisant le bytecode Java de toutes ses méthodes en codes binaires pour x86.
  Jusqu'à la fin du processus, toutes les références suivantes à la classe Toto appelleront directement le code binaire des fonctions, sans recompiler.
• Compilation JIT "par méthode": Au moment du "new Toto" ligne "1", la JVM fait seulement la compilation JIT du constructeur de la classe Toto (ici absent, donc rien à faire). Le "new Toto" en ligne "3" ne recompilera rien, puisque le constructeur est déjà traduit.
  Au moment du "t.hello()" ligne "2", la JVM fait la compilation JIT de la méthode Hello, traduisant son bytecode Java en codes binaires pour x86, puis fait un appel de fonction vers ces codes binaires.

Je ne sais pas lequel de ces deux scénarios est le vrai, mais c'est l'un des deux.

j'ai très bien compris. Merci.
Le JIT optimise les temps d'exécution, certes.
La compilation à la volée nécessite notamment pour la deuxième méthode que tu as citée, des accès mémoires répétitives (peut être plus que la compilation classique). En plus, à l'instant t, il n' y a pas que le processus de la méthode appelée qui doit avoir lieu mais également la tâche de la compilation à la volée.
Logiquement, et j'ai tord certainement puisque le JIT a fait ses preuves, tout cela constituent des freins. J'aurais raisonné en disant qu'il vaut mieux tout compiler d'un seul coup et lors de l'exécution, il n'y aura pas de tâche supplémentaires. C'est assez trompeur.

L'intéret majeur du Java, surtout à l'époque datant d'avant la compilation JIT, n'était pas les performances, loin de là: C'était la portabilité.
Dès qu'une JVM est écrite pour un système, tout code 100% java fonctionne dessus! Évidemment, toutes les parties en C (appelées par JNI) doivent généralement être réécrites, partiellement ou totalement. Dans tous les cas, ces parties doivent être recompilées.

Ensuite, la compilation JIT a permis d'augmenter les performances de façon drastique par rapport au semi-interprété. Évidemment, ce sera toujours un peu plus lent qu'un programme qui a été entièrement compilé à l'avance; mais ce qu'on perd en performance, on le gagne en portabilité.

De plus, le fait d'utiliser une machine virtuelle et un langage interprété ou semi-interprété est qu'on peut empêcher totalement un programme de trifouiller sa pile d'appels. Et ainsi, faire de la sécurité basée non plus sur les utilisateurs, mais sur les programmes. C'est ce qui permet de dire "seule cette classe/assembly a le droit d'écrire tel fichier", ou "cette classe/Assembly qui vient du Web n'a pas le droit de toucher à mon disque dur".
Dès qu'une partie non-sure du programme possède la possibilité de trafiquer sa pile d'appels, ceci est impossible. C'est pour cela qu'en .Net, seuls les assemblys "surs" ont le droit d'utiliser l'équivalent de JNI.

Portabilité et Sécurité d'abords!
Merci beaucoup.