Programmer Son Runtime, Sa Machine Virtuelle.

[Résolu]

Bonjour à tous,

J'aimerai faire part d'une idée qui traine dans ma tête depuis quelques jours ... j'ai cru comprendre que le grand soucis actuel dans la programmation est l'interopérabilité (pour preuve Sun a ouvert la voie avec Java, Microsoft a lancé DotNet, Adobe a lancé AIR, Etc...).

J'aimerai donc programmer ma propre machine virtuel (avec un nouveau langage de ma création ... sinon c'est pas assez compliqué !)

Pour cela je me doute qu'il faut commencer par un Analyseur Lexicale, Sémantique et autres joyeusetés du domaine. Une fois le code analysé et validé, on le transforme en code intermédiaire, on optimise le tout et ensuite on fini la transformation (langage cible).

l'idée est d'interpréter le code après avoir transformé le langage source en ASM (que je suis en train d'apprendre) et ce code ASM je fais comment pour l'interpréter ? :X c'est la que je bloque...

Le but de transformer le code source en ASM avant de l'interpréter c'est de récuperer la vitesse perdue, car un programme interprété sera toujours plus lent que ce même programme compilé.

Donc je remet clairement ici ma question :

Comment interprété du code ASM via une machine virtuelle (que je compte programmer moi-même) ? Est ce que cela est possible avant tout ^^ ?

J'ai l'impression que la notion du fonctionnement d'une machine virtuel m'échappe un peu n'hésitez pas à corriger mes bêtises !

Pour info's : Je commence l'ASM sinon j'ai l'habitude de programmer en C/C++.

La machine virtuelle n'interprète pas le code ASM: Elle l'exécute directement.
C'est pour ça que dans les histoires de sécurité, la machine virtuelle ne doit accepter d'exécuter que le code ASM qu'elle a généré elle-même: Celui issu de la traduction du langage intermédiaire (CIL pour .Net, Bytecode pour Java) en ASM.

Donc, sur le disque dur, les programmes compilés (.class ou .jar pour java, .exe pour .Net) sont encore en langage intermédiaire.

Ok merci pour l'information :)

Ces fameux codes intermédiaires sont donc stockés dans des fichiers que la machine virtuelle transforme en ASM et interprète directement ?

EDIT : les fichiers .jar ou .class sont "encodé" en binaire quelqu'un pourrai me préciser la méthode pour enregistrer ses fichiers intermédiaires en binaire ?

Eh bien, c'est un langage intermédiaire compilé, je ne vois pas trop quoi ajouter là-dessus.

Évidemment, il faut généralement aussi des en-têtes, ainsi, pour des langages comme Java et .Net, les informations décrivant les classes et leurs fonctions (noms des fonctions, types des paramètres etc.).

Typiquement, tu définis ton propre format numérique pour le code, et tu l'enregistres sous cette forme...

Un truc que tu peux faire, c'est bosser par étapes: Commencer par faire un compilo et une machine virtuelle capable d'interpréter directement le langage intermédiaire, puis en faire une qui le convertit en ASM d'abord. C'est ce qui a été fait pour Java, notamment.

ça me plait bien cette idée de travailler par étapes !

pour que ma machine virtuelle puisse interpréter le code intermédiaire je dois forcement transformer ce code en un langage compréhensible par l'ordinateur ... ou alors j'ai loupé une notion importante du fonctionnement d'une machine virtuel :X

Je pense que c'est le terme "interpréter" que tu confonds avec "traduire".

Interpréter, c'est la version lente: Le programme interpréteur lit les instructions fait ce qu'elles disent les instructions.

Exemple, un interpréteur [ame="http://en.wikipedia.org/wiki/Brainfuck"]Brainfuck[/ame] simplifié:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

void interpreteur_brainfuck(char const *code) { /*On restreint à une mémoire bornée, parce que la mémoire infinie, ça n'existe pas.*/ char memoire[TAILLE_MEMOIRE] = {0}; size_t ptr = 0; size_t iCode; for(iCode=0 ; code[iCode]!='\0' ; iCode++) { char c = code[iCode]; switch(c) { case '>': ptr++; break; case '<': ptr--; break; case '+': memoire[ptr]++; break; case '.': putchar(memoire[ptr]); break; case ',': memoire[ptr] = (char)getchar(); break; case '[': traiter_crochet_gauche(ptr, &iCode); break; case ']': traiter_crochet_droit(ptr, &iCode); break; } } }

---

Évidemment, le vrai code sera plus compliqué que le Brainfuck, et l'interpréteur plus compliqué également, mais c'est l'idée générale.

En effet j'ai confondu ces deux termes :) Merci à Toi !

j'ajoute un [Résolu] au titre !

Normalement, plutôt que modifier le titre, on utilise le bouton :resolu:

Au temps pour moi je n'avais pas vu ce bouton magique ...

Citation:

---

Envoyé par downyves

l'idée est d'interpréter le code après avoir transformé le langage source en ASM (que je suis en train d'apprendre) et ce code ASM je fais comment pour l'interpréter ?

---

Ce que tu décrit, c'est à peu de choses près Le projet bochs.

@downyves : Je crois que tu t'emmêles complètement les pinceaux entre tout plein de concepts.

Il y a déjà l'interprétation de programmes dans un langage de "haut" niveau (j'entends pas là "fait pour l'être humain", C, Java, C++, perl, Lisp, Haskell, n'importe). Ca consiste à parser le programme et à interpréter directement les différentes "phrases". Il n'y a aucune optimisation préalable, la représentation sous forme d'AST (arbre de syntaxe abstraite) est particulièrement peu adaptée, etc. Bref, c'est monstrueusement lent. Il n'y a plus que très peu de langage dans cette catégorie (peut être les shells ?)

Ensuite il y a la compilation directement vers langage machine (je ne parlerais pas d'assembleur qui peut être trompeur). On part d'un langage haut niveau, et on l'amène "directement" (il y a différente phase dans le compilo, mais elles sont généralement toutes exécutées directement à la suite les unes des autres) vers du code machine, que le processeur peut exécuter. C'est le cas des langages dit "compilés" comme C, C++, ocaml etc.
Intérêts : le code produit est exécuté directement par le processeur, donc pas d'intermédiaire, ça va "vite".
Inconvénients : le code produit l'est pour une seule architecture. Du code machine pour intel ou amd ne tournera jamais sur un PowerPC. Autre problème, il est très difficile de se convaincre quand on reçoit du code machine qu'il ne va pas faire de "bêtises" si on l'exécute sur notre ordinateur.

D'où l'idée de l'utilisation de machine virtuelle et de "byte code" (ou "code octet" en "français.."). Le principe est simple : on idéalise un ordinateur et on fixe son "langage machine". A partir de là, on peut compiler notre langage de haut niveau vers ce langage machine idéalisé. Problème, aucun processeur ne sait exécuter ce code. Il faut donc écrire une "machine virtuelle", c'est à dire un programme qui simule cet ordinateur idéalisé en exécutant le code octet. Il fait un peu l'interface entre le monde idéalisé du code octet et le monde réel de la machine. Mais à strictement parler, en fait il interprète le code octet. La différence principale étant que c'est un code linéaire, qu'on n'a donc pas à se trimbaler un AST et que l'interprèteur est une "simple" boucle while avec un gros switch compilé en table de saut. J'insiste qu'à la base, une machine virtuelle est un interprèteur d'un langage fortement simplifié (et justement conçu pour être interprété rapidement).
En écrivant une machine virtuelle par architecture et par OS (avec un peu de chance, en l'écrivant dans un C portable, la même machine virtuelle peut presque fonctionner partout sans trop de changement), on peut alors exécuter le code octet compilé une fois, et ce sur n'importe quelle architecture. De plus, si le langage "machine" de la VM est adapté, on peut faire des vérification a priori que le programme ne va pas faire de "bêtise". C'est ce que fait la VM java.

Mais il existe une sorte de juste milieu entre les deux dernières situation (et je pense que c'est de là que vient la confusion. Comme on l'a dit, une VM est un interprète de code octet. Donc à une instruction de code octet, par exemple "additionner", correspond plusieurs véritables instructions : récupérer le code octet, le décoder, voir que c'est une addition, récupérer les opérandes, effectuer l'opération, stocker le résultat. Donc même avec un langage adapté et une machine virtuelle optimisée, on est nettement plus lent que du code compilé directement (entre 10 et 100 fois plus lent, en gros). D'où l'idée de descendre d'un cran, d'aller du code octet vers le vrai langage machine du processeur (physique) hôte. Ceci est généralement fait à l'exécution du programme (on parle alors de compilation "just in time" (JIT), soit "juste à temps"). La machine virtuelle (après avoir vérifié l'innocuité du code octet dans le cas de java) compile des parties du byte code vers du langage machine. L'intérêt de la compilation JIT est que l'on peut attendre de voir dans quelles parties du bytecode le programme passe le plus de temps, et comment, pour choisir les parties à compiler et y appliquer des optimisations adaptées à l'exécution en cours. On peut ainsi parfois même battre des programmes compilés une fois pour toute, ou en tout cas rattraper une grosse partie de la différence de perf.
Mais là, attention, ce n'est pas du tout du même niveau que l'écriture d'une machine virtuelle ! Déjà, par essence, ce n'est pas portable puisqu'il faut produire du code en fonction de l'archi hôte. Ensuite, c'est de la vraie compilation, avec toutes les emmerdes qui vont avec (allocation des registre, sélection des bonnes instructions, etc, etc). Enfin, c'est de la vraie compilation compliquée ! Parce qu'il ne faut pas aller marcher sur les pieds de la machine virtuelle qui est toujours là. Pas question d'employer la pile système par exemple. Il faut faire attention aux registres. Il faut penser à rendre la main de temps à autres. Bref, c'est loin d'être simple.

Autant écrire une machine virtuelle peut être un exercice intéressant, compiler un langage jouet vers cette machine virtuelle peut être amusant. Autant écrire une VM avec compilo JIT intégré, faut pas rêver...

En effet en ayant réfléchi un peu à tout ça je me disais bien que c'était un projet de trop grande envergure :X

Merci pour toutes ces informations :)

Enfin tu peux faire un truc simple si tu n'optimises pas.

Par exemple, une machine à pile primitive, qui utiliserait la pile système, pas de sécurité ou pas de pointeurs ni d'accès aux bibliothèques natives, etc. Sur un x86, ça fait un jeu d'instructions assez réduit.

Citation:

---

Envoyé par downyves

J'aimerai donc programmer ma propre machine virtuel (avec un nouveau langage de ma création ... sinon c'est pas assez compliqué !)

Pour cela je me doute qu'il faut commencer par un Analyseur Lexicale, Sémantique et autres joyeusetés du domaine. Une fois le code analysé et validé, on le transforme en code intermédiaire, on optimise le tout et ensuite on fini la transformation (langage cible).

l'idée est d'interpréter le code après avoir transformé le langage source en ASM (que je suis en train d'apprendre) et ce code ASM je fais comment pour l'interpréter ? :X c'est la que je bloque...

---

salut le sujet est clos mais si tu veux faire ton propre langage interprété il ne faut pas du tout partir de l'ASM !
Il suffit de faire ton intepréteur en C ,une table des instructions puis une sorte de programme qui va comprendre les instructions et les intepréter.

LUA par exemple fait très bien cela ou bien Angel Script

Quitte à se taper l'écriture d'un interpréteur, autant le faire en ML...