Discussion :

[wafiwafi]

Bonjour à tous et à toutes.
Je me pose une question :
Le fichier binaire produit par le compilateur est il modifié avant qu'il arrive au microprocesseur qui exécutera instruction par instruction?
Je m'explique : Prenons l'exemple d'un langage (le c++) dont le compilateur produira le fichier en langage machine. Mais, rappelons nous qu'avant l'exécution du programme, le compilateur informe l'OS de la quantité de mémoire dont il a besoin...En plus l'OS prépare des zones mémoire pour le déroulement de l'exécution (code, données, pile et pourquoi pas le tas). Tout ce monde doit pouvoir préparer le terrain pour le processus qui va s'exécuter. Donc, pour moi, le microprocesseur doit recevoir des ordres binaires permettant par exemple de gérer les variables globales ou locales dans des zones mémoire spécifiques, ou encore réserver une zone au cas ou le programme a besoin de mémoire dynamique,....ect. Mais comme le processeur exécute un seul fichier binaire et instruction par instruction, cela me laisse à penser que tous les ordres pour la gestion citée sont tenus en compte dans ce même fichier; et comme la gestion du processus est accompli par l'OS alors le fichier binaire exécutable chargé en mémoire est modifié par l'OS. Cela me dérange par ce que je sais qu'il n'est pas modifié!. Alors je reviens vers vous pour éclaircissement.

[jabbounet]

Si tu parle d'une librairie ou d'un exécutable la réponse est non dans 99% des cas, le fichier binaire produit à la compilation n'est pas modifié. le 1% restant étant des cas en général ou ton système deviens inutilisable....



http://carl.seleborg.free.fr/cpp/cou...pts/le_PC.html

[wafiwafi]

Je parle d'un exécutable! Ce dernier ignore comme se déroulera le processus ni quelles ressources on mettra en œuvre. Alors comment le processeur saura par exemple que quand il rencontre le code d'une affectation d'une valeur à une variable, il doit la placer à une zone précise. Ce n'est qu'un exemple.
En fait ce qui m'échappe, c'est comment le processeur est courant de l'organisation du déroulement du processus tel que l'os l'a décidé?

[jabbounet]

le processeur ne sait rien de tout cela on lui fille juste un série d'instructions relativement basique a exécuter.


il suffit de regarder l'assembleur pour s'en rendre compte.

A la base sur les microprocésseurs
il y'a des instruction pour sotcker/lire des adresses mémoire (ces adresse sont en paramètres).
il y'a des instruction arithméthique et logique qui s'éxécute sur les registres
il y'a des instructions de saut et de branchement conditionnel.

Quelques autres qui sont venu enrichir le jeu d'unstruction des microprocesseur au fil du temps, mais la base reste simple.

[wafiwafi]

le processeur ne sait rien de tout cela on lui fille juste un série d'instructions relativement basique a exécuter.

Pour cela, on est entièrement d'accord. J'ai eu la chance de travailler sur 8086 et le 68000 pendant plusieurs années. Le principe reste le même comme tu disais.

Ce n'est pas là le problème; mais plutôt ce qui se passe avant de livrer la marchandise au processeur. Surtout que cette marchandise comme tu l'as bien dit est exécutée simplement instruction par instruction.

Néanmoins, je viens de lire que la partie gestion et allocation de la mémoire peut se passer de plusieurs manières jumelés ou non selon les langages:
1- pendant la compilation, et oui le compilateur peut organiser la mémoire; il peut insérer les ordres binaires adéquates destinés au processeur. Il peut même modifier des codes binaires (codes instructions, codes adresses mémoire) pour les adapter au but recherché.

2- pendant la compilation, mais ce coup ci, le compilateur travaille conjointement avec l'os pour décider des ordres binaires à insérer pour mieux organiser et prévoir le processus d'exécution.

3- pendant l'exécution, dans ce cas le compilateur n'est plus de la partie. Par contre, il se peut qu'il ait prédit un comportement et donc prévoir dans le code binaire un déroulement de gestion mémoire prévu à l'avance.

4- en plus du code binaire produit exécuté par le microprocesseur, l'os lance des modules qui préparent le terrain quand à l'organisation de la mémoire. Autrement dit, l'os mobilise des composants (couche matériel) qui par un système de codage gèrent la mémoire.

5- Enfin, il arrive qu'on organise la gestion de la mémoire à partir de la couche matériel. IL semble que cette procédure est dépassée et même déconseillée suite à la consommation gourmande des composants en énergie.

[jabbounet]

tu as a peu près 3 grandes écoles,

Celle du C/C++ et de tout les langages compilé.

il génèrent un code spécifique au microprocesseur/OS cible.

-> en gros tu recompile pour chaque type de plate forme supporté.
- exemple sunOS sur sparcIII ou linux sur x86_64

-> les librairies utilisées s'interfacent avec l'os qui s'interface avec le hard
- exemple le new/delete iront vérifier auprès de l'os que tu peux allouer/desallouer de la mémoire, l'os ira vérifier que la mémoire physique est disponible.


Celle de la machine virtuelle java

Tu génère un jeu d'instruction pour une machine virtuelle qui gérera tout ou presque
tu ne te pose pas les questions système sur les option de compilation à mettre.
pour savoir si ton appli supporte une plate forme particulière, il suffit de savoir si un jvm existe sur cette plate forme.

en contre partie tu es un peu plus lent à l'exécution, tu ne maitrise plus les aspect systèmes qui sont délégués a la jvm.


Celle des langage de script compilés à la volée (Perl , ...)


l'interpréteur de script te génère les instruction au moment de lancer le script (compilation à la volée) puis exécute les instructions générés (retour au cas C/C++).

c'est un peu plus lent que le C/C++ (temps de compilation inclus dans le temps d'execution) mais cela ne se ressent pas trop sur le matériel actuel en général.

[Mac LAK]

La chose qu'il te manque, c'est la phase de relocation.

En gros, un fichier exécutable est constitué des zones suivantes :

• Un entête permettant d'en connaître le format (PE, ELF, etc.).
• Une table d'importation, qui détermine quels sont les liens "natifs" de l'exécutables (vers des bibliothèques dynamiques). C'est cette zone qu'explorent des programmes comme "Dependancy Walker" ou "ldd".
• Une table de relocation (j'y reviendrais).
• Des zones de données : ce sont les zones exécutables (code segment), les données générales (data segment), etc.

Le code exécutable contenu dans le fichier binaire est dit relogeable : en effet, il ne contient AUCUNE adresse "en dur", mais seulement des adresses relatives (ou sauts courts), ou des étiquettes (sauts "lointains", ou simplement adresses dans d'autres modules, notamment dans les librairies dynamiques). En tant que tel, il ne peut donc absolument pas fonctionner tout seul, il n'est pas encore "exécutable" réellement. C'est bien du code machine, potentiellement exécutable, mais auquel il manque plein d'informations d'adresses.

C'est à ce stade que la table de relocation intervient : elle contient en effet TOUTES les emplacements d'adresses inconnues, et vers quoi ces adresses inconnues sont censées pointer. Lors du chargement de l'exécutable, le système d'exploitation va organiser en mémoire les différentes parties du fichier binaire, charger les DLL requises, puis une fois en possession de toutes les adresses "réelles" des modules manquants, il va patcher le code binaire avec les bonnes adresses "réelles", rendant ainsi le code réellement exécutable. Il va également créer les structures internes nécessaires pour que l'exécutable devienne un processus.

Une fois cette phase terminée, l'OS va réellement insérer dans son ordonnanceur (scheduler) le processus nouvellement créé, qui va donc pouvoir s'exécuter normalement jusqu'à ce qu'il soit terminé.


Côté tripaille interne, le code exécutable est une suite d'instructions en langage machine. La notion de variable n'existe plus, on parle de registres, d'adresses, de pile, etc. Pour de la doc sur cette phase, je te conseille de voir ce qu'est un compilateur, avec les pages associées bien sûr, ça t'éclaircira un peu le phénomène.