Pile de code d'octet contre trois adresses

Question

Lors de la conception d'un interpréteur de code d'octets, y a-t-il un consensus ces jours-ci sur la question de savoir si le format pile ou trois adresses (ou autre chose?) est meilleur?Je regarde ces considérations:

1. Le langage objectif est un langage dynamique assez similaire à Javascript.

2. Les performances sont importantes, mais la vitesse de développement et la portabilité le sont davantage pour le moment.

3. Par conséquent, l'implémentation sera strictement un interpréteur pour le moment;un compilateur JIT peut venir plus tard, si les ressources le permettent.

4. L'interpréteur sera écrit en C.

Answer 1

Jetez un œil à l'interpréteur de bytecode OCaml - il est l'un des plus rapides du genre.C'est à peu près une machine à pile, traduite en un code thread au chargement (en utilisant l'extension GNU computed goto).Vous pouvez également générer un code fileté de type Forth, ce qui devrait être relativement facile à faire.

Mais si vous gardez à l'esprit une future compilation JIT, assurez-vous que votre machine de pile n'est pas vraiment une machine de pile complète, mais plutôt une forme de sérialisation d'arbre d'expression (comme .NET CLI) - de cette façon vous 'd être capable de traduire votre bytecode «pile» en une forme à 3 adresses puis en une SSA.

Answer 2

Lisez L'évolution de Lua et L'implémentation de Lua 5.0 pour savoir comment Lua est passée d'une machine virtuelle basée sur une pile à une machine virtuelle basée sur des registres et pourquoi elle a gagné enil.

Answer 3

Des expériences faites par David Gregg et Roberto Ierusalimschy ont montré qu'un bytecode basé sur un registre fonctionne mieux qu'un bytecode basé sur une pile car moins d'instructions de bytecode (et donc moins de temps de décodage) sont nécessaires pour effectuer les mêmes tâches.Le format à trois adresses est donc clairement un gagnant.

Answer 4

Je n'ai pas beaucoup (pas vraiment) d'expérience dans ce domaine, vous voudrez peut-être vérifier certains des éléments suivants par vous-même (ou peut-être que quelqu'un d'autre pourra me corriger si nécessaire?).

Les deux langages avec lesquels je travaille le plus de nos jours sont C # et Java, donc je suis naturellement enclin à leurs méthodologies. Comme la plupart des gens le savent, les deux sont compilés en code octet, et les deux plates-formes (le CLR et la JVM) utilisent JIT (au moins dans les implémentations traditionnelles). De plus, je suppose que la nervosité de chaque plate-forme est écrite en C / C ++, mais je ne sais vraiment pas avec certitude.

Dans l'ensemble, ces langages et leurs plates-formes respectives sont assez similaires à votre situation (mis à part la partie dynamique, mais je ne sais pas si cela compte). De plus, comme ce sont des langages courants, je suis sûr que leurs implémentations peuvent servir de très bon guide pour votre conception.

---

Cela dit, je sais avec certitude que le CLR et la JVM sont des architectures basées sur la pile. Certains des avantages dont je me souviens pour les piles basées sur les piles et les registres sont

1. Code généré plus petit
2. Interprètes plus simples
3. Compilateurs plus simples
4. etc.

De plus, je trouve que le stack-based est un peu plus intuitif et lisible, mais c'est une chose subjective, et comme je l'ai déjà dit, je n'ai pas encore vu trop de code d'octets.

Certains avantages de l'architecture basée sur les registres sont

1. Moins d'instructions doivent être exécutées
2. Interprètes plus rapides (découle du n ° 1)
3. Peut plus facilement être traduit en code machine, car la plupart des matériels courants sont basés sur des registres
4. etc.

Bien sûr, il existe toujours des moyens de compenser les inconvénients de chacun, mais je pense que ceux-ci décrivent les éléments évidents à prendre en compte.

Answer 5

Si vous avez JIT en tête, les bytecodes sont la seule option.

Juste au cas où vous pourriez jeter un œil sur mon TIScript: http:// www.codeproject.com/KB/recipes/TIScript.aspx et sources: http://code.google.com/p/tiscript/