Discussion :

[Sve@r]

Mais tout d'abord je souhaite m'assure d'une chose. Une fois le binaire/exécutable produit. Comment se passe son exécution ?

J'aurais tendance à répondre "super bien"...

Donc EC vas exécuter les ordres un par un, lorsqu'il arrive sur l’équivalent binaire de

Code :

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

int c = a + b;

il demande à l'OS l'usage des registres du CPU plus l'ordre pour faire l'addition puis que l'OS lui crée une zone mémoire (c) pour y mettre le résultat. De là j'ai 2 interrogations/incertitude:
+ tout d'abord, le type étant perdu à ce moment, le code binaire devra donc contenir la longueur de la zone mémoire.

En fait le compilateur, sachant qu'il manipule des int (2 octets), crée des ordres en assembleur de manipulation octet par octet.
Et en plus ces 2 octets peuvent être codés dans le sens de lecture (donc je simplifie "123456" sera "0012" puis "3456") ou dans le sens inverse (donc 123456 sera codé "3456" puis "0012" ce qu'on nomme "little-endian" ou "big-endian") le truc doit se démerder pour gérer le sens avec chaque octet.

+ Ma seconde interrogation (c'est ma question de départ) comment fait l'OS pour garder une trace du "propriétaire" de chaque zone mémoire.

Ben là...
Ce que je pense, c'est que chaque zone étant "nommée" (par le nom des variables), chaque zone lui sera associé un registre. Donc pour c=a+b il devrait y avoir un truc genre "move a to r1" puis "move b to r2" puis "r3=r1+r2" puis "move r3 to c". Et tout ça en gérant en plus les octets.

Si vraiment ça t'intéresse, il te faut t'orienter maintenant vers l'assembleur car c'est l'étape suivante de compilation d'un code C...

[chrtophe]

il demande à l'OS l'usage des registres du CPU

Absolument pas. Lors de l'appel d'un fonction, certains registres doivent être préservés, d'autres non. cela signifie que si tu veux toucher au registres devant être préservés, tu dois les sauvegarder (ça se fait sur la pile), puis les restaurer avant de quitter la fonction. Ca s'appelle la convention d'appel. Chaque processus à ses propres valeurs de registre pendant son execution, en cas de changement de processus actif, l'ordonnanceur effectuera une commutation de contexte.

comment fait l'OS pour garder une trace du "propriétaire" de chaque zone mémoire.

Chaque processus a son propre espace d'adressage, c'est le rôle de la MMU. Ils vont partager en commun l'accès (réglementé) à l'espace noyau, et l'accès à des bibliothèques partagées qui ne seront chargées qu'une fois en mémoire, mais dispo pour tous les processus les ayant chargé dans leur espace d'adressage. Pour le reste, chaque processus à son espace d'adressage inaccessible aux autres processus.

Mais tout d'abord je souhaite m'assure d'une chose. Une fois le binaire/exécutable produit. Comment se passe son exécution ?
Admettons que le binaire contient les ordres de l’exécution du programme(du type mettre valeur A dans registre E1 mettre B dans registre E2 mettre somme d'E1 et E2 dans la zone mémoire 0x0395). Quel logiciel/programme les lis et les exécutent ?

A ce stade, ce n'est plus un logiciel qui exécute le code mais le processeur. Il va exécuter les instructions les unes à la suite des autres, sauf en cas d’instruction de saut (suivant en général une instruction de test), dans ce cas l'adresse de saut est incluse dans l'instruction. L'adresse de la prochaine instruction exécutée est stockée dans le registre EIP en 32 bits/RIP en 64 bits sur x86 nommé pointeur d'instruction. Le rôle de l'OS va être de créer la structure du du nouveau processus, d'y réserver la RAM nécessaire, d'y charger le contenu de l'exe, d’affecter les valeurs de base des registres (au moins le pointeur d'instruction et le pointeur de pile), et d'ajouter le nouveau processus dans la liste des processus actifs.

Tu n'as pas à t'occuper de tout ceci au niveau C.

[chrtophe]

J'aurais tendance à répondre "super bien"...

J'aurais tendance à dire que ça dépend du code

[Médinoc]

Mais tout d'abord je souhaite m'assure d'une chose. Une fois le binaire/exécutable produit. Comment se passe son exécution ?
(snip)
+ Ma seconde interrogation (c'est ma question de départ) comment fait l'OS pour garder une trace du "propriétaire" de chaque zone mémoire.

L'OS utilise la Memory Management Unit (MMU, de nos jours intégrée au processeur) pour gérer la mémoire (RAM physique et "virtuelle", i.e. le pagefile) sous forme de "pages", et d'une liste indiquant à quelles pages le processeur, dans son état (contexte) actuel, a le droit d'accéder (avec des droits séparés pour lecture, écriture et exécution).

Du point de vue de l'OS, à chaque contexte correspond un fil d'exécution (thread) et un processus:

• Chaque processus possède sa propre liste de pages mémoires auquel il a accès ; dans ces pages mémoires sont chargées son code et ses données.
• Chaque thread possède le contexte lui-même: Principalement, l'emplacement pour sauvegarder l'intégralité des registres du processeur quand ce thread n'est pas celui en cours d'exécution.

Supposons que tu aies un programme simple qui lit le contenu d'un fichier, fait un traitement sur ce contenu, et écrit la sortie sur un autre fichier. Lors du lancement de ce programme, l'OS:

• Crée un nouveau processus
• Alloue des pages mémoire pour ce processus
• Charge le contenu de l'exécutable dans ces pages mémoire
• Crée un nouveau thread
• Place l'exécution du thread au début du programme (en gros, il lit le Entry Point indiqué dans l'exécutable et copie cette adresse dans la "sauvegarde du registre Instruction Pointer (IP)" du thread).
• Place le thread dans sa liste "prêt à exécuter"

Le reste, c'est le travail de l'ordonnanceur (le code, faisant partie du noyau de l'OS, qui gère l'exécution des processus). À intervalles réguliers (sous Windows, c'est 64 fois par seconde, donc toutes les 16ms environ), l'horloge va interrompre le processeur. Ce qui se passe alors:

• Tous les registres sont sauvegardés et leur valeur finit dans la zone de sauvegarde des registres du thread actuel.
• L'exécution saute au code de l'ordonnanceur,
• L'ordonnanceur remet le thread actuel au bout de la liste "prêt à exécuter".
• L'ordonnanceur regarde le prochain thread "prêt à exécuter"
• Si ce thread est dans un autre processus, alors l'ordonnanceur change aussi la liste de pages accessibles.
• L'ordonnanceur charge les registres sauvegardés de ce nouveau thread.
• L'ordonnanceur termine l'interruption; l'exécution reprend dans le nouveau thread.

Lorsqu'un thread est en cours d'exécution, son code (ses instructions en langage machine) sont directement exécutés sur le processeur, jusqu'à ce qu'il soit interrompu.

[Kannagi]

ah ? pour quelle raison un tel changement ? où ou comment apprend-on de telle information ?

La micro-architecture n'a aucun rapport avec la programmation ,si c'est ce qui t’intéresse alors je te conseille de lire : "Computer Architecture: A Quantitative Approach" de David Patterson et John L. Hennessy

Il en est ressorti que pour les CPU c'est un argument marketing et pour l'OS, la différence de bits permet un adressage plus long donc plus de mémoire (en gros).

Ce que tu dis n'a aucun sens , comment un OS 64 bits pourrait fonctionner sur un proc 32 bits, si c'est purement marketing ?
L'OS ne peut pas adresser plus que le CPU lui permet donc tu inverse là.
C'est parce que le CPU permet un adressage plus long que l'OS le peut aussi.

Donc non c'est pas "marketing" de parler de CPU 64 bits, ça permet des adressages plus long ,que l'OS utilisera ensuite pour accéder à plus de RAM.

ce n'est que ça. Si je peux comprendre le fonctionnement sous-jacent, cela m'enrichis et si en plus, par "effets de bord", j’étends encore un peu plus mes horizons/connaissances, c'est du bonus.

Ce que tente de dire chrtophe (je pense) et que la programmation n'a rien n'a voir avec le hardware, si tu veux t’améliorai à la prog , alors c'est algorithmique qu'il faudra se concentrer.
En soit le fonctionnement du CPU n'a que peu "d'importance" , parce que tu n'y sera jamais confronté.
Même si tu code en asm , sur du x86 , ben savoir comment fonctionne le CPU dans les détails ne sera pas fort utile (sauf grosse optimisation) , d'ailleurs c'est un erreur courante de pas mal de programmeur sur du x86 de croire que le CPU fonctionne de façon séquentiel par exemple , où qu'il exécute les instructions un a un.

[chrtophe]

Ce que tente de dire chrtophe (je pense) et que la programmation n'a rien n'a voir avec le hardware

Au sens pur C non. le C se fout effectivement du matériel et même du CPU. Il impose uniquement 16 bits minimum pour un int par exemple. Si tu crée un compilateur qui affecte 32 bits pour un int, tu devras limiter l'int à la plage utilisable avec 16 bits à savoir -32767 à +32767 (ou 0 à 65535 avec un unsigned int), sinon tu ne respectes pas la norme. Mais aucun intérêt, car tu as le type long pour 32 bits. Et si dans ton code, tu ne vérifies pas les dépassements, tu t'exposes à de sacrés bugs.

Pour écrire une chaine sur la sortie standard, tu vas utiliser printf, qui n'est pas du C pur mais une fonction externe de la libc. La libc peut très bien être écrite en autre chose que du C, tant qu'elle respecte les conventions d'appels. Tu peux utiliser autre chose que la libc, c'est par exemple le cas sous Windows ou tu vas utiliser les fonctions win32. Tu n’utiliseras par exemple pas printf pour écrite une chaine dans une fenêtre, même sous Linux.