- Il te faut d'abord créer divers compilateurs, pour divers langages, qui génèrent tous un même fichier "exécutable", basé sur des bytecode, opcodes, etc. Tout ce que tu veux, mes des instructions "à toi", indépendante de la plate-forme matérielle (processeur) ou logicielle (système d'exploitation). Donc, par exemple, tu écris un compilateur C qui produira un fichier biniou.code. Ou un compilateur Java qui produira un fichier biniou.code. - Ensuite, la fameuse machine virtuelle. Ce n'est rien d'autre qu'un interpréteur de tes comamndes "à toi" comme dit plus haut. Donc, un programme qui lit le contenu de biniou.code et, à la volée, le traduit en instruction de la plate-forme sur laquelle s'exécute ta machine virtuelle. C'est là le gag, parce qu'il te faudra une machine virtuelle pour Windows, une pour Linux, une pour Apple, etc ou, au minimum, pour chaque processeur sur lequel tu comptes que ta machine virtuelle puisse tourner.
Je schématise à 200 à l'heure.
Par exemple, ton compilo C, qui tourne disons sous Windows va traduire l'instruction i++; en , un opcode à toi. Cet opcode sera contenu dans le ficheir "exécutable" biniou.code.
Ensuite, t'écris une machine virtuelle qui, lorsquelle lit ton biniou.code et voit inc_local_var_one_unit le traduit en inc eax, par exemple sur un processeur Intel. Mais en autre chose sur un processeur ARM.
Et ainsi de suite.
Pas dur à comprendre, mais un boulot de malade à mettre au point...
-- AMcD®
http://arnold.mcdonald.free.fr/
En quelques mots c'est pas compliqué.
- Il te faut d'abord créer divers compilateurs, pour divers langages, qui
génèrent tous un même fichier "exécutable", basé sur des bytecode, opcodes,
etc. Tout ce que tu veux, mes des instructions "à toi", indépendante de la
plate-forme matérielle (processeur) ou logicielle (système d'exploitation).
Donc, par exemple, tu écris un compilateur C qui produira un fichier
biniou.code. Ou un compilateur Java qui produira un fichier biniou.code.
- Ensuite, la fameuse machine virtuelle. Ce n'est rien d'autre qu'un
interpréteur de tes comamndes "à toi" comme dit plus haut. Donc, un
programme qui lit le contenu de biniou.code et, à la volée, le traduit en
instruction de la plate-forme sur laquelle s'exécute ta machine virtuelle.
C'est là le gag, parce qu'il te faudra une machine virtuelle pour Windows,
une pour Linux, une pour Apple, etc ou, au minimum, pour chaque processeur
sur lequel tu comptes que ta machine virtuelle puisse tourner.
Je schématise à 200 à l'heure.
Par exemple, ton compilo C, qui tourne disons sous Windows va traduire
l'instruction i++; en , un opcode à toi. Cet opcode sera contenu dans le
ficheir "exécutable" biniou.code.
Ensuite, t'écris une machine virtuelle qui, lorsquelle lit ton biniou.code
et voit inc_local_var_one_unit le traduit en inc eax, par exemple sur un
processeur Intel. Mais en autre chose sur un processeur ARM.
Et ainsi de suite.
Pas dur à comprendre, mais un boulot de malade à mettre au point...
- Il te faut d'abord créer divers compilateurs, pour divers langages, qui génèrent tous un même fichier "exécutable", basé sur des bytecode, opcodes, etc. Tout ce que tu veux, mes des instructions "à toi", indépendante de la plate-forme matérielle (processeur) ou logicielle (système d'exploitation). Donc, par exemple, tu écris un compilateur C qui produira un fichier biniou.code. Ou un compilateur Java qui produira un fichier biniou.code. - Ensuite, la fameuse machine virtuelle. Ce n'est rien d'autre qu'un interpréteur de tes comamndes "à toi" comme dit plus haut. Donc, un programme qui lit le contenu de biniou.code et, à la volée, le traduit en instruction de la plate-forme sur laquelle s'exécute ta machine virtuelle. C'est là le gag, parce qu'il te faudra une machine virtuelle pour Windows, une pour Linux, une pour Apple, etc ou, au minimum, pour chaque processeur sur lequel tu comptes que ta machine virtuelle puisse tourner.
Je schématise à 200 à l'heure.
Par exemple, ton compilo C, qui tourne disons sous Windows va traduire l'instruction i++; en , un opcode à toi. Cet opcode sera contenu dans le ficheir "exécutable" biniou.code.
Ensuite, t'écris une machine virtuelle qui, lorsquelle lit ton biniou.code et voit inc_local_var_one_unit le traduit en inc eax, par exemple sur un processeur Intel. Mais en autre chose sur un processeur ARM.
Et ainsi de suite.
Pas dur à comprendre, mais un boulot de malade à mettre au point...
-- AMcD®
http://arnold.mcdonald.free.fr/
Eric
Si chaque instruction est traduite puis interprétée, on perd un temps fou. On ne peut donc pas tout programmer ainsi ou alors il faut des machines super rapide. J'ai bien compris ?
Aurais-tu un source d'une petite machine virtuelle, pour voir un peu le fonctionnement.
Eric
Si chaque instruction est traduite puis interprétée, on perd un temps fou.
On ne peut donc pas tout programmer ainsi ou alors il faut des machines
super rapide.
J'ai bien compris ?
Aurais-tu un source d'une petite machine virtuelle, pour voir un peu le
fonctionnement.
Si chaque instruction est traduite puis interprétée, on perd un temps fou. On ne peut donc pas tout programmer ainsi ou alors il faut des machines super rapide. J'ai bien compris ?
Aurais-tu un source d'une petite machine virtuelle, pour voir un peu le fonctionnement.
Eric
AMcD®
Eric wrote:
Si chaque instruction est traduite puis interprétée, on perd un temps fou.
C'est traduit en tes commandes à toi une seule fois, lors de la génération du fichier qui contient le code qui sera interprété par la VM.
Évidemment que ça prend du temps ! Une VM c'est à l'opposé du concept de rapidité ou d'optimisation, réfléchis un peu... dès que t'interprète, il y a le goulet représenté par le temps de traduction du code intermédaire. Difficile d'y échapper.
On ne peut donc pas tout programmer ainsi ou alors il faut des machines super rapide.
Ben regarde le code .Net, le Java. Ça marche pas trop mal. C'est clair que plus la machine est rapide... Mais bon, ça dépend aussi du type de code intermédiaire généré. C'est évident que si tes instructions intermédiaires sont encodés comme les instructions Intel, t'es pas prêt de gagner un concours de vitesse...
J'ai bien compris ?
Heu, il me semble.
Aurais-tu un source d'une petite machine virtuelle, pour voir un peu le fonctionnement.
Non, j'ai pas ça sous la main. Mais regarde par exemple le code HTML. Dis-toi que c'est le code intermédiaire généré par un compilateur. La machine virtuelle, c'est tout navigateur qui peut l'interpréter. Is it plus clair ?
-- AMcD®
http://arnold.mcdonald.free.fr/
Eric wrote:
Si chaque instruction est traduite puis interprétée, on perd un temps
fou.
C'est traduit en tes commandes à toi une seule fois, lors de la génération
du fichier qui contient le code qui sera interprété par la VM.
Évidemment que ça prend du temps ! Une VM c'est à l'opposé du concept de
rapidité ou d'optimisation, réfléchis un peu... dès que t'interprète, il y a
le goulet représenté par le temps de traduction du code intermédaire.
Difficile d'y échapper.
On ne peut donc pas tout programmer ainsi ou alors il faut des
machines super rapide.
Ben regarde le code .Net, le Java. Ça marche pas trop mal. C'est clair que
plus la machine est rapide... Mais bon, ça dépend aussi du type de code
intermédiaire généré. C'est évident que si tes instructions intermédiaires
sont encodés comme les instructions Intel, t'es pas prêt de gagner un
concours de vitesse...
J'ai bien compris ?
Heu, il me semble.
Aurais-tu un source d'une petite machine virtuelle, pour voir un peu
le fonctionnement.
Non, j'ai pas ça sous la main. Mais regarde par exemple le code HTML.
Dis-toi que c'est le code intermédiaire généré par un compilateur. La
machine virtuelle, c'est tout navigateur qui peut l'interpréter. Is it plus
clair ?
Si chaque instruction est traduite puis interprétée, on perd un temps fou.
C'est traduit en tes commandes à toi une seule fois, lors de la génération du fichier qui contient le code qui sera interprété par la VM.
Évidemment que ça prend du temps ! Une VM c'est à l'opposé du concept de rapidité ou d'optimisation, réfléchis un peu... dès que t'interprète, il y a le goulet représenté par le temps de traduction du code intermédaire. Difficile d'y échapper.
On ne peut donc pas tout programmer ainsi ou alors il faut des machines super rapide.
Ben regarde le code .Net, le Java. Ça marche pas trop mal. C'est clair que plus la machine est rapide... Mais bon, ça dépend aussi du type de code intermédiaire généré. C'est évident que si tes instructions intermédiaires sont encodés comme les instructions Intel, t'es pas prêt de gagner un concours de vitesse...
J'ai bien compris ?
Heu, il me semble.
Aurais-tu un source d'une petite machine virtuelle, pour voir un peu le fonctionnement.
Non, j'ai pas ça sous la main. Mais regarde par exemple le code HTML. Dis-toi que c'est le code intermédiaire généré par un compilateur. La machine virtuelle, c'est tout navigateur qui peut l'interpréter. Is it plus clair ?
-- AMcD®
http://arnold.mcdonald.free.fr/
Frederic Bonroy
Eric a écrit :
Si chaque instruction est traduite puis interprétée, on perd un temps fou. On ne peut donc pas tout programmer ainsi ou alors il faut des machines super rapide. J'ai bien compris ?
Vous pouvez interpréter chaque instruction à chaque fois que vous la rencontrez, en effet. Selon ce que doit faire votre programme ça risque d'être lent, oui.
L'alternative, c'est de compiler. En gros et pour reprendre l'exemple d'Arnold, vous écrivez un second compilateur qui à partir de biniou.code (le code source pour ainsi dire), crée biniou.exe si l'utilisateur est sous Windows/x86, et qui lance ce biniou.exe qui s'exécutera comme un programme Windows normal. Et cela se passe en toute transparence sans que l'utilisateur ne s'en aperçoive. (Au lieu de créer un fichier biniou.exe vous pouvez aussi générer le code directement en mémoire, mais bon, le principe est le même.)
Si votre machine virtuelle permet au code de se modifier lui-même, alors cette traduction statique ne fonctionnera pas et il vous faudra compiler dynamiquement: vous divisez le code en blocs logiques et vous compilez puis exécutez chaque bloc individuellement. Vous pouvez aussi réutiliser ces blocs (pratique pour les boucles qui exécutent plusieurs fois le même code), ce qui vous évite de les retraduire à chaque fois - sauf si, justement, un bloc a été modifié. Mais dans ce cas il suffit de retraduire ce bloc là, pas les autres. Là vous combinez vitesse d'exécution et souplesse, mais c'est plus compliqué (car il faut détecter les modifications de zones mémoires).
Aurais-tu un source d'une petite machine virtuelle, pour voir un peu le fonctionnement.
Pas de code source, mais vous pouvez vous inspirer de documents sur l'émulation, les principes sont similaires pour ne pas dire identiques. Justement je m'intéresse à ce sujet en ce moment, c'est pourquoi je peux vous donner quelques liens:
Sinon une petite recherche Google a donné ceci (je ne sais pas ce que ça vaut, je n'ai pas lu ces documents): http://www.ifi.unizh.ch/richter/people/pilz/thesis/Thesis.html http://www.cis.nctu.edu.tw/~wuuyang/papers/bytecode2X86.BRIEF.pdf
Je sais qu'il y a une description du langage "machine" (façon de parler) de la machine virtuelle Java quelque part, mais je ne la retrouve pas.
Eric a écrit :
Si chaque instruction est traduite puis interprétée, on perd un temps fou.
On ne peut donc pas tout programmer ainsi ou alors il faut des machines
super rapide.
J'ai bien compris ?
Vous pouvez interpréter chaque instruction à chaque fois que vous la
rencontrez, en effet. Selon ce que doit faire votre programme ça risque
d'être lent, oui.
L'alternative, c'est de compiler. En gros et pour reprendre l'exemple
d'Arnold, vous écrivez un second compilateur qui à partir de biniou.code
(le code source pour ainsi dire), crée biniou.exe si l'utilisateur est
sous Windows/x86, et qui lance ce biniou.exe qui s'exécutera comme un
programme Windows normal. Et cela se passe en toute transparence sans
que l'utilisateur ne s'en aperçoive.
(Au lieu de créer un fichier biniou.exe vous pouvez aussi générer le
code directement en mémoire, mais bon, le principe est le même.)
Si votre machine virtuelle permet au code de se modifier lui-même, alors
cette traduction statique ne fonctionnera pas et il vous faudra compiler
dynamiquement: vous divisez le code en blocs logiques et vous compilez
puis exécutez chaque bloc individuellement. Vous pouvez aussi réutiliser
ces blocs (pratique pour les boucles qui exécutent plusieurs fois le
même code), ce qui vous évite de les retraduire à chaque fois - sauf si,
justement, un bloc a été modifié. Mais dans ce cas il suffit de
retraduire ce bloc là, pas les autres.
Là vous combinez vitesse d'exécution et souplesse, mais c'est plus
compliqué (car il faut détecter les modifications de zones mémoires).
Aurais-tu un source d'une petite machine virtuelle, pour voir un peu le
fonctionnement.
Pas de code source, mais vous pouvez vous inspirer de documents sur
l'émulation, les principes sont similaires pour ne pas dire identiques.
Justement je m'intéresse à ce sujet en ce moment, c'est pourquoi je peux
vous donner quelques liens:
Sinon une petite recherche Google a donné ceci (je ne sais pas ce que ça
vaut, je n'ai pas lu ces documents):
http://www.ifi.unizh.ch/richter/people/pilz/thesis/Thesis.html
http://www.cis.nctu.edu.tw/~wuuyang/papers/bytecode2X86.BRIEF.pdf
Je sais qu'il y a une description du langage "machine" (façon de parler)
de la machine virtuelle Java quelque part, mais je ne la retrouve pas.
Si chaque instruction est traduite puis interprétée, on perd un temps fou. On ne peut donc pas tout programmer ainsi ou alors il faut des machines super rapide. J'ai bien compris ?
Vous pouvez interpréter chaque instruction à chaque fois que vous la rencontrez, en effet. Selon ce que doit faire votre programme ça risque d'être lent, oui.
L'alternative, c'est de compiler. En gros et pour reprendre l'exemple d'Arnold, vous écrivez un second compilateur qui à partir de biniou.code (le code source pour ainsi dire), crée biniou.exe si l'utilisateur est sous Windows/x86, et qui lance ce biniou.exe qui s'exécutera comme un programme Windows normal. Et cela se passe en toute transparence sans que l'utilisateur ne s'en aperçoive. (Au lieu de créer un fichier biniou.exe vous pouvez aussi générer le code directement en mémoire, mais bon, le principe est le même.)
Si votre machine virtuelle permet au code de se modifier lui-même, alors cette traduction statique ne fonctionnera pas et il vous faudra compiler dynamiquement: vous divisez le code en blocs logiques et vous compilez puis exécutez chaque bloc individuellement. Vous pouvez aussi réutiliser ces blocs (pratique pour les boucles qui exécutent plusieurs fois le même code), ce qui vous évite de les retraduire à chaque fois - sauf si, justement, un bloc a été modifié. Mais dans ce cas il suffit de retraduire ce bloc là, pas les autres. Là vous combinez vitesse d'exécution et souplesse, mais c'est plus compliqué (car il faut détecter les modifications de zones mémoires).
Aurais-tu un source d'une petite machine virtuelle, pour voir un peu le fonctionnement.
Pas de code source, mais vous pouvez vous inspirer de documents sur l'émulation, les principes sont similaires pour ne pas dire identiques. Justement je m'intéresse à ce sujet en ce moment, c'est pourquoi je peux vous donner quelques liens:
Sinon une petite recherche Google a donné ceci (je ne sais pas ce que ça vaut, je n'ai pas lu ces documents): http://www.ifi.unizh.ch/richter/people/pilz/thesis/Thesis.html http://www.cis.nctu.edu.tw/~wuuyang/papers/bytecode2X86.BRIEF.pdf
Je sais qu'il y a une description du langage "machine" (façon de parler) de la machine virtuelle Java quelque part, mais je ne la retrouve pas.
Eric
Merci à tout les deux,
Justement, je m'intéresse à la programmation d'un émulateur et j'essaie de voir toute les possibilités.
Merci pour les liens, je vais allé voir.
Petite question avant : Si je veux un émulateur 68000 sur un 87xxx avec une émulation de diverses adresses et hardware le tout avec une vitesse appréciable, j'interprète comment les instructions assembleur ? Un petit code ???
Eric
Merci à tout les deux,
Justement, je m'intéresse à la programmation d'un émulateur et j'essaie de
voir toute les possibilités.
Merci pour les liens, je vais allé voir.
Petite question avant : Si je veux un émulateur 68000 sur un 87xxx avec une
émulation de diverses adresses et hardware le tout avec une vitesse
appréciable, j'interprète comment les instructions assembleur ?
Un petit code ???
Justement, je m'intéresse à la programmation d'un émulateur et j'essaie de voir toute les possibilités.
Merci pour les liens, je vais allé voir.
Petite question avant : Si je veux un émulateur 68000 sur un 87xxx avec une émulation de diverses adresses et hardware le tout avec une vitesse appréciable, j'interprète comment les instructions assembleur ? Un petit code ???
Eric
AMcD®
Frederic Bonroy wrote:
L'alternative, c'est de compiler. En gros et pour reprendre l'exemple d'Arnold, vous écrivez un second compilateur qui à partir de biniou.code (le code source pour ainsi dire), crée biniou.exe si l'utilisateur est sous Windows/x86, et qui lance ce biniou.exe qui s'exécutera comme un programme Windows normal.
Certes mon ami, mais alors, il ne s'agit plus de virtualisation, mais d'une espèce de portage.
-- AMcD®
http://arnold.mcdonald.free.fr/
Frederic Bonroy wrote:
L'alternative, c'est de compiler. En gros et pour reprendre l'exemple
d'Arnold, vous écrivez un second compilateur qui à partir de
biniou.code (le code source pour ainsi dire), crée biniou.exe si
l'utilisateur est sous Windows/x86, et qui lance ce biniou.exe qui
s'exécutera comme un programme Windows normal.
Certes mon ami, mais alors, il ne s'agit plus de virtualisation, mais d'une
espèce de portage.
L'alternative, c'est de compiler. En gros et pour reprendre l'exemple d'Arnold, vous écrivez un second compilateur qui à partir de biniou.code (le code source pour ainsi dire), crée biniou.exe si l'utilisateur est sous Windows/x86, et qui lance ce biniou.exe qui s'exécutera comme un programme Windows normal.
Certes mon ami, mais alors, il ne s'agit plus de virtualisation, mais d'une espèce de portage.
-- AMcD®
http://arnold.mcdonald.free.fr/
Eric
Mon gros problème en informatique c'est de ne pas parler l'anglais, des docs en français ça existe ?
Eric
Mon gros problème en informatique c'est de ne pas parler l'anglais, des docs
en français ça existe ?
Mon gros problème en informatique c'est de ne pas parler l'anglais, des docs en français ça existe ?
Eric
AMcD®
Eric wrote:
Mon gros problème en informatique c'est de ne pas parler l'anglais, des docs en français ça existe ?
Heu là, tu peux d'ores et déjà laisser ici toute espérance. Dès que tu vas t'attaquer à des instructions processeur, des documents système, de la compilation, etc. C'est uniquement en anglais. Dans la masse de documents t'auras peut-être 1 truc pas mal en français, mais ce sera du style 0.000001 %. Les gros trucs, c'est uniquement en anglais.
Pas de chance :-(.
-- AMcD®
http://arnold.mcdonald.free.fr/
Eric wrote:
Mon gros problème en informatique c'est de ne pas parler l'anglais,
des docs en français ça existe ?
Heu là, tu peux d'ores et déjà laisser ici toute espérance. Dès que tu vas
t'attaquer à des instructions processeur, des documents système, de la
compilation, etc. C'est uniquement en anglais. Dans la masse de documents
t'auras peut-être 1 truc pas mal en français, mais ce sera du style 0.000001
%. Les gros trucs, c'est uniquement en anglais.
Mon gros problème en informatique c'est de ne pas parler l'anglais, des docs en français ça existe ?
Heu là, tu peux d'ores et déjà laisser ici toute espérance. Dès que tu vas t'attaquer à des instructions processeur, des documents système, de la compilation, etc. C'est uniquement en anglais. Dans la masse de documents t'auras peut-être 1 truc pas mal en français, mais ce sera du style 0.000001 %. Les gros trucs, c'est uniquement en anglais.
Pas de chance :-(.
-- AMcD®
http://arnold.mcdonald.free.fr/
Eric
Je me débrouille pas mal, si j'ai du code. Les document pdf de Fredecic vont me paraissent tres interessant, je vais les traduire avec un traducteur qui me donnera les grandes lignes. Si vous avez d'autres docs je suis preneur (surtout en français biensur).
Eric
Je me débrouille pas mal, si j'ai du code. Les document pdf de Fredecic vont
me paraissent tres interessant, je vais les traduire avec un traducteur qui
me donnera les grandes lignes.
Si vous avez d'autres docs je suis preneur (surtout en français biensur).
Je me débrouille pas mal, si j'ai du code. Les document pdf de Fredecic vont me paraissent tres interessant, je vais les traduire avec un traducteur qui me donnera les grandes lignes. Si vous avez d'autres docs je suis preneur (surtout en français biensur).
Eric
Vincent Burel
"Eric" wrote in message news:4290fd2e$0$1221$
Merci à tout les deux,
Petite question avant : Si je veux un émulateur 68000 sur un 87xxx avec
une
émulation de diverses adresses et hardware le tout avec une vitesse
Renseignez vous auprès de Motorola, mais je pense que ca existe déjà. généralement les outil de dev DSP sont livré avec émulateur PC pour pouvoir debugger plus rapidemment du code...
VB
"Eric" <ericcity@caramail.com> wrote in message
news:4290fd2e$0$1221$8fcfb975@news.wanadoo.fr...
Merci à tout les deux,
Petite question avant : Si je veux un émulateur 68000 sur un 87xxx avec
une
émulation de diverses adresses et hardware le tout avec une vitesse
Renseignez vous auprès de Motorola, mais je pense que ca existe déjà.
généralement les outil de dev DSP sont livré avec émulateur PC pour pouvoir
debugger plus rapidemment du code...
Petite question avant : Si je veux un émulateur 68000 sur un 87xxx avec
une
émulation de diverses adresses et hardware le tout avec une vitesse
Renseignez vous auprès de Motorola, mais je pense que ca existe déjà. généralement les outil de dev DSP sont livré avec émulateur PC pour pouvoir debugger plus rapidemment du code...
