J'ai une question toute bête. Je me suis rendu compte, étant développeur que je n'avais pas assez de connaissance sur le langage bas niveau, juste à titre d'information et savoir comment ça marche.
Lorsqu'on développe un code en langage c/c++ par exemple, il compile le code source en code machine exécutable. C'est la partie de transformation en code machine qui m'intéresse.
Lorsque je code directement en assembleur, j'utilise nasm par exemple pour traduire mon code assembleur en code machine.
Première question: Le nasm est conçu par les constructeurs de pc, ou n'importe qui peut créer un programme qui traduit le code assembleur en code machine? comment on fait un traducteur genre nasm, comment créer un exe ou un executable linux? comment sont les fichiers exe ou executable linux?
Il y a plusieurs années, au tout début, comme j'ai appris que l'ordinateur ne comprenait que le 01, j'ai ouvert un éditeur texte et j'ai tapé une suite de 01 pour voir comment l'ordinateur allait réagir (c'est tout bête, mais c'est comme cela qu'on est curieux en faisant des trucs complètement idiot). et rien ne s'est passé. je n'ai plus cherché a comprendre, je programme en c/c++, php, etc, sans chercher à comprendre.
Mais je suis très curieux. Maintenant je veux vraiment comprendre comment communique un pc de bout en bout, mais coté développement, pas une histoire de carte mère,etc (sauf si nécessaire). et comment moi je peux faire un compilateur genre nasm, juste pour comprendre vraiment de manière approfondie comment les exécutables linux ou windows ou autres sont conçus, pas juste une connaissance théorique, mais en le faisant moi-même.
Donc si il y a des sources claires, ou si vous pouvez me détailler et comment développer un genre de nasm très basique, je vous remercie de m'aider vraiment.
C'est tout bête mais merci de prendre la peine de me guider pas à pas (je ne compte pas faire un compilateur révolutionnaire (je vais continuer à utiliser nasm ou tasm, etc), mais juste construire un compilateur pour comprendre vraiment comment ça marche. Même si certains penseront que c'est une tâche ardue et perdue, j'ai pas peur d'essayer, c'est ainsi que j'ai compris pas mal de choses.
Je connais déja le c/c++, assembleur, php, et asm (déja fait des projets d'entreprise qui fonctionnent et des projets personnels, même en assembleur), mais je suis nul dans la compréhension réelle du langage machine, de la traduction de mon code en machine.
Merci à tous
Tant qu'on vie, faisons ce que nous pouvons et faisons le bien!
Salut, je suis moi-même dans la conception d'un compilateur pour mon propre langage, je vais donc répondre avec cette expérience.
sajreborn a écrit:
Lorsqu'on développe un code en langage c/c++ par exemple.
D'abord, sache que "C/C++", ça n'existe pas. C'est C ou C++ (deux langages bien distincts).
sajreborn a écrit:
(1) Le nasm est conçu par les constructeurs de pc, ou n'importe qui peut créer un programme qui traduit le code assembleur en code machine? (2) Comment on fait un traducteur genre nasm, comment créer un exe ou un executable linux? comment sont les fichiers exe ou executable linux?
(1) Nasm est un (langage) assembleur dit à "macro". Il n'existe pas que lui, il y en a plusieurs : NASM, MASM, FASM, YASM, TASM, ...
Un (langage) assembleur n'est pas nécessairement créé par les développeurs des systèmes d'exploitation ou par les constructeurs de CPU. En effet, on peut dire que les langages que j'ai cités sont des abstractions sur l'architecture originelle du CPU.
Le plus couramment, les CPU fonctionnent sur des architectures INTEL, dont la norme d'assembleur actuel est x86-64. x86-64 est l'assembleur "fourni" par/avec le CPU. Voir ici, un poste que j'ai écrit sur le fonctionnement des assembleurs et leurs jeux d'instructions.
Par exemple, l'assembleur FASM a été conçu pour l'architecture x86-64 par un développeur qui n'appartient à aucune entreprise spécifique de construction de PC ou d'OS. Il est très sympa d'ailleurs. Et n'importe qui peut concevoir son assembleur.
(2) C'est relativement simple. Une instruction assembleur correspond à une suite logique d'octets. Par exemple :
mov eax,0x4c
Correspond à ceci dans la mémoire :
0: b8 4c 00 00 00
Les nombres diffèrent (légèrement) selon les systèmes d'exploitation; ce qui fait que sous Linux, la conversion HL en LL est différente de sous Windows.
Concernant l'exécution, ce n'est pas magique. Il faut voir l'OS comme un très très gros programme qui ne fait qu'émuler les instructions qu'on lui donne sur le CPU.
sajreborn a écrit:
Il y a plusieurs années, au tout début, comme j'ai appris que l'ordinateur ne comprenait que le 01, j'ai ouvert un éditeur texte et j'ai tapé une suite de 01 pour voir comment l'ordinateur allait réagir (c'est tout bête, mais c'est comme cela qu'on est curieux en faisant des trucs complètement idiot). et rien ne s'est passé. je n'ai plus cherché a comprendre, je programme en c/c++, php, etc, sans chercher à comprendre.
0 et 1 ne sont que des représentations.
0 → pas de charges électrique ;
1 → charge électrique.
Et puis, à partir de ça et d'une série de transistors formant des ports logiques, on obtient une machine programmable.
Moi aussi, lorsque j'étais plus petit, j'ai essayé de faire un .exe avec des 0 et des 1. Mais, évidemment, cela n'a pas fonctionné. Pourquoi ?
Simplement parce que ce n'est pas si simple. Lorsque l'ordinateur lit le programme, il a besoin de savoir plusieurs choses :
Quoi faire ;
Où faire ;
Comment faire.
J'explique tout ça dans le lien que je t'ai donné précédemment.
sajreborn a écrit:
(1) Mais je suis très curieux. Maintenant je veux vraiment comprendre comment communique un pc de bout en bout, mais coté développement, pas une histoire de carte mère,etc (sauf si nécessaire). (2) Comment moi je peux faire un compilateur genre nasm, juste pour comprendre vraiment de manière approfondie comment les exécutables linux ou windows ou autres sont conçus, pas juste une connaissance théorique, mais en le faisant moi-même.
(1) J'explique tout ça dans le lien que je t'ai donné précédemment.
(2) C'est assez compliqué de créer un assembleur. Il y a moult choses à prendre en compte pour pouvoir rendre un programme exécutable à partir de ton propre assembleur. Si tu veux vraiment savoir comment fonctionne un exécutable sous Windows ou sous Linux, je te conseillerais de prendre connaissance des éditeurs de liens.
sajreborn a écrit:
Donc si il y a des sources claires, ou si vous pouvez me détailler et comment développer un genre de nasm très basique, je vous remercie de m'aider vraiment.
Pour faire très basique, tu pourrais peut-être commencé par créer un émulateur pour NASM. Par exemple, tu entres ceci :
msg db 'Hello, world!'
main:
push epb
mov ebp, esp
mov eax, [msg]
int 21h
pop eax
mov esp, ebp
ret
Ton émulateur pourrait interpréter chaque instruction ;
...
switch (instr) {
case TOKEN::IDENTIFIER:
...
break;
case TOKEN::DB:
...
break;
case TOKEN::STRING:
...
break;
...
};
...
Et, grâce à des fonctions pré-intégrées dans le programme, donner un résultat correspondant. J'en ai déjà fait un, et ce n'est, certes, pas très optimal, mais cela peut-être un début si on débute. Voici un exemple.
Si tu es plus confirmé(e), je ne connais pas de tutoriel sur la création d'assembleur. Et c'est normal, très peu sont les personnes qui font ça. Mais, normalement, si tu détiens suffisamment des connaissances, tu devrais pouvoir y arriver.
sajreborn a écrit:
C'est tout bête mais merci de prendre la peine de me guider pas à pas (je ne compte pas faire un compilateur révolutionnaire (je vais continuer à utiliser nasm ou tasm, etc), mais juste construire un compilateur pour comprendre vraiment comment ça marche. Même si certains penseront que c'est une tâche ardue et perdue, j'ai pas peur d'essayer, c'est ainsi que j'ai compris pas mal de choses.
Je veux bien essayer de te guider dans cette aventure, mais franchement, ce n'est pas facile. Autant parser un fichier assembleur, c'est simple, autant construire un éditeur de liens, ... (l'éditeur de liens c'est le processus / programme qui transforme un fichier objet ou une bibliothèque en dll ou exécutable). Il faudra aussi étudier les formats d'exécutable de l'OS ciblé :
Windows → PE ;
Linux → ELF.
sajreborn a écrit:
Je connais déja le C et le C++, assembleur, php, et asm (déja fait des projets d'entreprise qui fonctionnent et des projets personnels, même en assembleur), mais je suis nul dans la compréhension réelle du langage machine, de la traduction de mon code en machine.
J'espère qu’après cette lecture, et celle du lien que je t'ai donné(e), tu comprendras déjà mieux
- Edité par vanaur 17 juillet 2018 à 13:08:02
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
Concernant l'exécution, ce n'est pas magique. Il faut voir l'OS comme un très très gros programme qui ne fait qu'émuler les instructions qu'on lui donne sur le CPU.
Euh non. L'OS se contente de préparer ce qui va être nécessaire de son côté au niveau du code qui doit être chargé mais après, il ne fait rien de plus que transmettre les données de l'exécutable à la machinerie du processeur. Tout ce qui va changer ensuite c'est que certaines instructions passeront par une demande réalisée à l'OS lorsqu'elles représentent un point crucial pour la sécurité. Mais heureusement que les instructions ne sont pas lues par l'OS avant d'être exécutées sinon ce serait une horreur à l'exécution.
Pour ce qui est de la traduction depuis un langage ASM like vers du code machine, il n'y a vraiment rien de compliqué. La traduction des opérations est vraiment du one-to-one. Il n'y a rien d'intéressant là dedans, il faut juste se pencher sur la documentation du processeur et relier bêtement les mnémoniques à des valeurs entières. Il y a juste les bibliothèques à gérer et ces éléments là sont plutôt à voir du côté de la documentation du format d'exécutable qui dépend de l'OS.
Bref : il y a pas grand chose d'intéressant là dedans : tout est abstrait par l'interface du processeur.
Je me suis peux-être effectivement mal exprimé sur certains points, merci de m'avoir corrigé
Ksass`Peuk a écrit:
Pour ce qui est de la traduction depuis un langage ASM like vers du code machine, il n'y a vraiment rien de compliqué. La traduction des opérations est vraiment du one-to-one.
Certes, c'est bêtement chercher la correspondance d'une instruction en code machine, mais l'exécution d'un code, ce n'est pas si simple que ça dans l'absolu.
Ksass`Peuk a écrit:
Il y a pas grand chose d'intéressant là dedans : tout est abstrait par l'interface du processeur.
Moi je trouve ça intéressant. Quand tu te dis que tout ton système d'exploitation, tes programmes, tes jeux, ect. ... tournent grâce à ça...
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
Certes, c'est bêtement chercher la correspondance d'une instruction en code machine, mais l'exécution d'un code, ce n'est pas si simple que ça dans l'absolu.
L'exécution est un peu plus compliquée mais pour le coup tu n'as pas vraiment la main dessus. D'ailleurs la manière d'exécuter dépend pas mal de l'OS mais également de l'architecture du processeur. Il y a des choses qui sont faites par micro-code sur certains chips, sur d'autre non, etc. Bref, c'est un peu le bordel de ce côté.
De manière générale, ce qui touche à la phase d'édition des liens c'est le bordel complet et pas du tout pour les bonnes raisons. Les règles actuelles pour faire un linker c'est "arrangez vous pour faire comme les autres". Sachant que le "comme les autres" est défini nulle part. C'est tellement la merde que des gens lancent des projets de recherche là dessus. Juste pour comprendre ce qui se passe là dedans.
vanaur a écrit:
Ksass`Peuk a écrit:
Il y a pas grand chose d'intéressant là dedans : tout est abstrait par l'interface du processeur.
Moi je trouve ça intéressant. Quand tu te dis que tout ton système d'exploitation, tes programmes, tes jeux, ect. ... tournent grâce à ça...
Ce qui se passe pendant l'exécution c'est intéressant. Réaliser la traduction depuis un ASM-like vers du code machine c'est vraiment juste fastidieux et de la lecture de documentation mal écrite.
Raison pour laquelle j'ai choisi l'assembleur FASM. Il a (presque) tout pour être parfait :
Langage à macro évoluée ;
Technologie SSSO (Same Source Same Output) pour chaque OS (Windows, Linux, Mac et DOS) ;
Éditeur de lien "intégré" au compilateur, donc aucun problème avec ça (et il est assez performant depuis le v2 : 1.00) ;
Instructions virtuelle (= instructions à micro-code, notamment pour manipuler les données lourdes) ;
...
Ksass`Peuk a écrit:
Ce qui se passe pendant l'exécution c'est intéressant. Réaliser la traduction depuis un ASM-like vers du code machine c'est vraiment juste fastidieux et de la lecture de documentation mal écrite.
Il existe des outils pour se faciliter la tâche, et encore, ils ne sont effectivement pas tous performant aux vues de la "documentation", et ce n'est en effet pas très intéressant, ni très utile dans la plupart des cas.
____
J'ai posé la question, par curiosité, au créateur de FASM (Tomasz Grysztar) pour voir à quel point cela était difficile de créer un assembleur, et voici sa réponse si cela peut intéressé quelqu'un.
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
Désolé si j'ai mis du temps à répondre, mais j'ai lu vos réponses il y a 3 jours, et j'ai pris la peine de faire des recherches en fonction de vos interventions.
Effectivement, voici ce que m'a apporté toutes vos interventions et mes recherches selon vos apports:
-Il faut un compilateur pour macher le code source en un code assembleur
-Puis un assembleur pour generer le code source: j'ai effectivement constaté que ce n'est pas facile, mais bon!
Je ne savais même pas les rôles de chacun (compilateur et asembleur), ni même ce que c'était qu'un assembleur. Je connaissait la notion de code assembleur et je prenais FASM, ou TASM etc pour des compilateurs, mais c'est un programme assembleur ou assembleur tout court.
Mais je vais suivre les conseils de vanaur pour éditer un interpréteur d'abord (pour une personne qui a de l'expérience dans ce domaine il vaut mieux suivre ses conseil pour acquérir ce qu'on cherche).
Franchement merci beaucoup à vous vanaur et à Ksass`Pe uk (vous avez donné des orientations qui m'ont aidé pendant ces trois jours de recherche personnel.
Je vais commencer par ce que vous m'avez donné comme informations, et m'orienter vers l'exemple de vanaur.
Maintenant, je vais m'y plonger pour voir la difficulté par moi meme: concevoir, realiser, tester et affiner et tirer des lecons.
Sincerement, vous avez pris la peine de bien détailler, c'est pour cela que j'ai pris du temps avant de répondre, pour bien exploiter vos informations.
Maintenant j'ai une procédure pour atteindre mes objectifs: je comprends mieux le rôle d'un compilateur qui est de formater le code source (macher le travail, détecter les erreurs de syntaxe, voir la grammaire, etc) afin de le donner à l'assembleur afin qu'il construise au mieux l’exécutable selon l'architecture cible (c'est bien cela?)
J'aurai bien voulu avoir déjà votre expérience, à tous les deux, mais je vais m'y mettre.
Juste une question, me conseillez vous d'utiliser un assembleur ou créer un pour l'instant vu qu'il est important pour passer de code source à exe? (priorité des taches en fait)
Quels outils, Dans quels langages et pour quelle architecture cible? (pour un débutant comme moi)
Tant qu'on vie, faisons ce que nous pouvons et faisons le bien!
Personnellement, je te conseillerai de plutôt utiliser LLVM qui est pas trop mal documenté. On peut le voir comme un assembleur générique de haut niveau. C'est suffisant pour commencer : c'est assez bas niveau pour avoir une traduction intéressante, et on peut déjà s'amuser à faire des optimisations au niveau du code LLVM. Et ça retire les phases de traduction finale qui ne sont pas très intéressantes.
Pour le langage de départ, soit un langage joué avec ta propre syntaxe, soit un sous-ensemble d'un langage facile à analyser, comme Pascal. Pour la manipulation, je te conseille un langage de plutôt haut niveau, comme Ocaml ou Haskell, et d'utiliser un générateur de parser pour ton langage (par exemple Menhir pour Ocaml).
Le rôle d'un compilateur est de formater le code source afin de le donner à l'assembleur pour qu'il construise au mieux l’exécutable selon l'architecture cible (c'est bien cela?)
Oui. Mais attention aux termes utilisés. "Formater le code source" ne sont en effet pas les mots que j'aurais employés. Un compilateur ne formate pas vraiment du code, il le traduit, et corrige ou prévient des éventuelles erreurs. Il peut également passer par un système de bytecode, comme pour Java (j'y viens plus loin).
Le compilateur analyse ce texte, puis en conclut qu'il n'y a pas d'erreurs (seuls quelques avertissements en fonction des compilateurs, en effet, sous GCC int main() est à préférer).
Durant la phase de l'analyse sémantique, il a créé ce qu'on nomme un AST (arbre syntaxique abstrait). Quelque chose ressemblant à ceci sous Clang (c'est un compilateur pour C++) :
Cet AST est ensuite traduit en code assembleur (il peut également y avoir d'autres étapes avant ou après, mais c'est dans les grandes lignes) :
.LC0:
.string "Hello!"
main:
push rbp
mov rbp, rsp
mov esi, OFFSET FLAT:.LC0
mov edi, OFFSET FLAT:_ZSt4cout
call _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
mov esi, OFFSET FLAT:_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
mov rdi, rax
call _ZNSolsEPFRSoS_E
mov eax, 0
leave
ret
_Z41__static_initialization_and_destruction_0ii:
push rbp
mov rbp, rsp
sub rsp, 16
mov DWORD PTR [rbp-4], edi
mov DWORD PTR [rbp-8], esi
cmp DWORD PTR [rbp-4], 1
jne .L5
cmp DWORD PTR [rbp-8], 65535
jne .L5
mov edi, OFFSET FLAT:_ZStL8__ioinit
call _ZNSt8ios_base4InitC1Ev
mov eax, OFFSET FLAT:_ZNSt8ios_base4InitD1Ev
mov edx, OFFSET FLAT:__dso_handle
mov esi, OFFSET FLAT:_ZStL8__ioinit
mov rdi, rax
call __cxa_atexit
.L5:
leave
ret
_GLOBAL__I_main:
push rbp
mov rbp, rsp
mov esi, 65535
mov edi, 1
call _Z41__static_initialization_and_destruction_0ii
leave
ret
Ensuite, l'assembleur se charge de compiler se code en code machine suivant une table de conversion tel que celle-ci.
sajreborn a écrit:
Juste une question, me conseillez vous d'utiliser un assembleur ou créer un pour l'instant vu qu'il est important pour passer de code source à exe? (priorité des taches en fait)
Ne te fatigue pas à en créer un. Cela n'apporte pas grand-chose (même si cela peut être une belle expérience), surtout lorsque l'on débute. Utilise en un. Je te conseillerais NASM ou FASM. NASM parce que sa communauté est vaste, et FASM, parce que si tu as des questions, je saurai probablement d'aider.
sajreborn a écrit:
Quels outils, Dans quels langages et pour quelle architecture cible? (pour un débutant comme moi)
Commence par un projet qui vise ton système d'exploitation, ainsi tu auras surement plus de faciliter. L'architecture, si tu décides de créer un assembleur interprété, c'est toi qui la choisis. Je conseillerais sous des 16 bits pour commencer. Concernant le langage, celui que tu maîtrises devrait faire l'affaire. Mais si tu décides de faire un émulateur (donc de "l'asm interprété"), diriges-toi plutôt vers un langage compilé, ainsi tu auras de meilleures performances.
Et préfère également un langage fonctionnel, ils sont assez adaptés pour ce type de projet.
Une autre option s'offre à toi : compiler vers un bytecode. Comme Ksass`Peuk vient de le dire, LLVM est un très bon choix, c'est une infrastructure de compilation offrant des outils très utile pour la réalisation de langage de programmation, et proposant son propre système d'assembleur. En voici un petit exemple :
define i32 @square(i32) local_unnamed_addr #0 {
%2 = mul nsw i32 %0, %0
ret i32 %2
}
Ceci serait donc l'assembleur haut niveau à générer par ton compilateur pour une fonction C-like que voici :
int square(n) {
return n * n;
}
Comme tu le vois, ce n'est pas très différent. Il suffit juste de comprendre la logique de cet assembleur afin de pouvoir en générer efficacement. Voici le résultat en x86-64 sous Clang :
square:
imul edi,edi
mov eax,edi
ret
Cette manière de faire est plus constructive dans le sens où tu as la capacité de créer un compilateur optimisé, performant et utilisable à une moindre mesure selon le langage que tu désires implémenter.
Il en existe évidemment d'autres, comme le bytecode de la JVM, ou encore du bytecode Lua, Python, ... ou même ton propre bytecode.
PS: Désoler pour les quelques potentielles fautes d’orthographe, j'ai été vite pour rédiger ce message et je n'ai pas le temps de me relire Si j'ai fait des erreurs, n'hésitez pas à m'en faire part.
- Edité par vanaur 25 juillet 2018 à 16:37:28
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
Tout d'abord merci pour la peine de me corriger par rapport à la terminologie, car si, on ne se comprend pas sur les termes, difficile d’échanger (vanaur, n'hésite pas à me corriger sur les termes car je préfère cela). Cela dit, je corrige ma phrase "Formater le code source"en traduire le code, et dans ce cas j'ai une autre façon de concevoir le compilateur.
Je te rassure, j'ai pas vu d'erreurs (à mois que j'ai des lacunes en orthographe). Au fait à te lire, je sais que tu es très méticuleux dans tes travaux (ce qui est permet de se parfaire).
bien compris, je crois que j'ai finalement compris le fonctionnement d'un exécutable: et pour m'assurer que toutes vos explications et les recherches ont servit, je résume:
-En fait L'OS est comme un GROS ÉMULATEUR, et qui comprend un format d’exécutable donnée, voilà pourquoi .exe ne fonctionne pas de manière natif sous Linux et vice versa pour elf coté Linux;
-Un assembleur crée un fichier sous un certain format compréhensible par l'OS qui peut alors l'exécuter selon les droits de ce dernier (Pour qu'il n'affecte pas le noyau par exemple).
-Donc si je m’entraîne à concevoir une sorte d'émulateur (ou interpréteur de code), alors :
*Je crée un compilateur qui prend le fichier source en entrée, traite ce fichier et me donne un fichier qui peut être traduit par mon interpréteur (comme un exe ou elf qui est compris par Windows ou Linux, ou l'autre pour Mac);
*Je créer un interpréteur qui lit mon fichier compilé sous un format, et selon son contenu (ses instructions donc) il fait quelque chose: soit afficher un texte, soit faire des additions, etc;
Bien sur mon interpréteur sera compris par on OS (je suis sous Linux en fait) qui lui aussi est le gros interpréteur.
Dans ce cas, on interpréteur sera comme l'OS et mon fichier généré par mon compilateur comme un exe.
J'ai essayé d'expliquer avec des mots simples.
Si j'ai tout bon, je crois que je vais clore et mettre en résolu et m'inspirer maintenant de vos interventions pour pratiquer, pratiquer, pratiquer, etc....., pratiquer.
Alors?
( Question de curiosité:
1. Quel est le premier OS et comment fut-il construit? il y avait déjà des compilateurs? J'ai cherché et j'ai vu qu'ils utilisaient des cartes perforées.
2.Ceux qui ont programmé le premier Linux ou Unix, le tout premier noyau avaient quoi comme OS de base? Windows?
)
- Edité par sajreborn 27 juillet 2018 à 20:50:30
Tant qu'on vie, faisons ce que nous pouvons et faisons le bien!
Je te rassure, j'ai pas vu d'erreurs (à mois que j'ai des lacunes en orthographe). Au fait à te lire, je sais que tu es très méticuleux dans tes travaux (ce qui est permet de se parfaire).
Merci
sajreborn a écrit:
En fait L'OS est comme un GROS ÉMULATEUR, et qui comprend un format d’exécutable donnée, voilà pourquoi .exe ne fonctionne pas de manière natif sous Linux et vice versa pour elf coté Linux;
Attention encore une fois; cette fois-ci, c'est ma faute, j'avais été trop rapide dans ma façon de m'exprimer, Ksass`Peuk m'avait alors corrigé :
Ksass`Peuk avait écrit:
L'OS se contente de préparer ce qui va être nécessaire de son côté au niveau du code qui doit être chargé mais après, il ne fait rien de plus que transmettre les données de l'exécutable à la machinerie du processeur...
Avant de continuer, il faut distinguer deux éléments :
Système d'exploitation (abrégé OS) ;
Processeur (aussi appelé CPU).
Le système d'exploitation, comme l'avait dit Ksass`Peuk, ne se charge pas d'exécuter un programme par lui-même, il permet juste de créer un lien avec le CPU pour que celui-ci puisse, lui, exécuter le code (assemblé par l'assembleur). L'OS, dans tout ça, à plus un rôle de "sécurité" pour l'utilisateur et ses données. Il n'émule pas le code (j'y reviens après), mais veille au bon déroulement du programme et se charge également de réserver des espaces en mémoire. Il offre également des possibilités d'accès à certains éléments au développeur du programme, tel que la possibilité de créer une interface graphique selon les normes de l'OS (on remarque que le GUI n'est pas le même sous Windows que sous Linux par exemple).
sajreborn a écrit:
Donc si je m’entraîne à concevoir une sorte d'émulateur (ou interpréteur de code), alors :
*Je crée un compilateur qui prend le fichier source en entrée, traite ce fichier et me donne un fichier qui peut être traduit par mon interpréteur (comme un exe ou elf qui est compris par Windows ou Linux, ou l'autre pour Mac);
Oui, mais généralement, l'émulateur ne fait qu'exécuter le code. Par exemple, on peut émuler un jeu NES (NES est une ancienne marque de console de jeux 16 bits) sous Windows. L'émulateur se charge alors d'interpréter le code pour que l'utilisateur ait directement un résultat. Par exemple :
05 .OPT OBJ
10 *= $0600
0100 ; CIO
0110 ICHID = $0340 ;IOCB 0 S:
0120 ICCOM = $0342 ;IOCB Command
0130 ICBAL = $0344 ;Xfer Buffer Adr
0140 ICBAH = $0345
0150 ICPTL = $0346 ;PutByte Adr
0160 ICPTH = $0347
0170 ICBLL = $0348 ;Buffer Len
0180 ICBLH = $0349
0190 CIOV = $E456 ; CIO Vector
0500 ; Setup CIO Call
0510 LDX #0 ;IOCB 0
0520 LDA #9 ;Put Cmd Val
0530 STA ICCOM,X ;Set it as the cmd
0540 LDA #HELLO&255 ;Str low byte
0550 STA ICBAL,X
0560 LDA #HELLO/256 ;Str high byte
0570 STA ICBAH,X
0580 LDA #0 ;Str Len low byte
0590 STA ICBLL,X
0600 LDA #$FF ;Str Len high byte
0610 STA ICBLH,X
0620 ; Call CIO
0630 JSR CIOV
0640 RTS
1000 HELLO .BYTE "Hello World!",$9B
L'émulateur reçoit directement ce code-ci, qu'il se charge ensuite d'interpréter. Mais en aucun cas un émulateur ne compile.
Ce code pourrait, par exemple, être le résultat de la compilation d'un code haut niveau qui aurait été compilé par ton compilateur :
Bien sur mon interpréteur sera compris par on OS (je suis sous Linux en fait) qui lui aussi est le gros interpréteur.
Je suis vraiment navré, tu as retenu une mauvaise information à cause de moi... Comme dit plus haut donc, l'OS n'interprète rien.
Pour plus d'informations, tu peux aller (re)lire ce poste-ci. Il explique en fait comment le CPU fait pour exécuter un programme.
sajreborn a écrit:
Si j'ai tout bon, je crois que je vais clore et mettre en résolu et m'inspirer maintenant de vos interventions pour pratiquer, pratiquer, pratiquer, etc....., pratiquer.
Fait bien la part des choses entre OS et CPU, c'est important.
sajreborn a écrit:
Quel est le premier OS et comment fut-il construit? il y avait déjà des compilateurs?
C'est une longue histoire avant d'arriver jusqu'ici. En fait, au début, il n'y avait pas d'OS. Juste des machines programmables avec des sets d'instructions binaires. Puisque écrire de longues suites de 0 et de 1 (après s'est ajouté l’hexadécimal) n'était pas très rapide, ni sûr, on a créé un système d'one-two-one, qui permettait de faire correspondre une série de lettres à une instruction d'opcode, par exemple :
011001 010101 000101 010101
Pourrait correspondre à ceci :
push eax
inc eax
Pour la petite histoire, les missiles de la première guerre mondiale étaient programmés avec un tel système. S'il y avait ne serait-ce qu'une petite erreur, ce missile pouvait exploser en plein vol ou atterrir à un endroit non voulu.
Les premiers système d'exploitation sont arrivés progressivement. Le premier était LEO I selon cette source (- source).
sajreborn a écrit:
Ceux qui ont programmé le premier Linux ou Unix, le tout premier noyau avaient quoi comme OS de base? Windows?
Absolument pas Linus Torvalds (créateur de Linux, et maître absolu du langage C) avait, en gros, participé à la création des logicielles GNU sous UNIX et, par la suite, a conçu le noyau Linux; il publie son noyau sous une licence GNU GPL et fait donc évoluer son système.
Windows, quant à lui, est beaucoup plus... obscure dans sa réalisation. Certains disent que Bille Gate aurait copié les codes de Steve Jobs par exemple. Quoi qu'il en soit, Bille Gate a bel et bien conçue un langage de programmation haut niveau (BASIC) pour un système Altair 8800. Ensuite il entreprend des partenariats avec IBM pour créer un nouveau système d'exploitation : DOS; puis, plus tard, le premier Windows apparaît.
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
L'émulateur reçoit directement ce code-ci, qu'il se charge ensuite d'interpréter. Mais en aucun cas un émulateur ne compile.
Notons qu'il pourrait tout à fait compiler .
vanaur a écrit:
C'est une longue histoire avant d'arriver jusqu'ici. En fait, au début, il n'y avait pas d'OS. Juste des machines programmables avec des sets d'instructions binaires. Puisque écrire de longues suites de 0 et de 1 (après s'est ajouté l’hexadécimal) n'était pas très rapide, ni sûr, on a créé un système d'one-two-one, qui permettait de faire correspondre une série de lettres à une instruction d'opcode.
Pour être plus précis (et je vous renvoie au bouquin de A. Tanenbaum : Modern Operating System), on avait surtout des machines à cartes perforées, puis on est relativement rapidement passés sur des machines à bandes magnétiques et puis sur des machines plus "modernes".
vanaur a écrit:
sajreborn a écrit:
Ceux qui ont programmé le premier Linux ou Unix, le tout premier noyau avaient quoi comme OS de base? Windows?
Absolument pas Linus Torvalds (créateur de Linux, et (1) maître absolu du langage C) avait, en gros, (2) participé à la création des logicielles GNU sous UNIX et, par la suite, a conçu le noyau Linux; il publie son noyau sous une licence GNU GPL et fait donc évoluer son système.
(1) LOL.
(2) C'est surtout qu'à l'époque, il était étudiant et que Minix (qui était le plus utilisé dans son école) coûtait littéralement un bras. C'est pour ça qu'il a entrepris d'écrire Linux.
vanaur a écrit:
Certains disent que Bille Gate aurait copié les codes de Steve Jobs par exemple.
C'est particulièrement du flan : la très vaste majorité du code pondu à cette époque du côté de Jobs l'a été par Steve Wozniak. Steve Jobs, c'est un type qui faisait bosser des gens ensembles et qui était très bon en marketing.
C'était une métaphore Ce qui est sûr par contre, c'est qu'il est meilleur que moi.
Ksass`Peuk a écrit:
Steve Jobs, c'est un type qui faisait bosser des gens ensembles et qui était très bon en marketing.
Ça, c'est sûr. Je ne suis même pas certain qu'il ait un jour réellement programmé ou même travailler activement sur un projet. Je renvoie d'ailleurs a la vidéo de Poissons Fécond sur le sujet, elle est assez sympa en terme d'anecdotes.
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
Désolé, je n'étais pas disponible ces derniers jours, mais j'ai bossé sur le sujet.
Bon, Je fais des recherches supplémentaires pour une mise au point sur mes connaissances sur certains sujets (système d'exploitation, programme, compilation, édition de liens, processeur, etc.) car je constate que 'ai beaucoup de lacunes sur certaines notions importantes que l'on néglige parfois.
En tout cas merci pour le temps que vous aviez pris pour me répondre.
Toutes vos informations seront mise à profit.
Merci franchement.
Tant qu'on vie, faisons ce que nous pouvons et faisons le bien!
Certaines notions importantes que l'on néglige parfois.
Parfois, il y a des notions qui ne méritent effectivement pas de réels intérêts (même si, des fois, elles jouent un rôle important). Tu risques de perdre du temps à essayer de comprendre le fonctionnement de quelque chose qui ne te sert pas directement (l'éditeur de liens par exemple). Ou du moins, tu pourrais juste essayer de savoir ce que ça fait dans les grandes lignes.
Tu peux également mettre ton sujet [résolu].
Bonne continuation.
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
Fonctionnement d'un Compilateur
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...