9 votes

Écrire un compilateur ; quelle VM ?

Je vais essayer d'écrire un compilateur pour un langage dynamique. De préférence pour une machine virtuelle existante --- je ne veux pas (encore) m'occuper de la collecte des déchets et de la myriade d'autres problèmes qu'une bonne machine virtuelle gère pour vous. Quelles machines virtuelles suggérez-vous ?

Je suis sous Linux, donc je ne sais pas si .NET (via Mono) est une bonne idée. J'ai entendu dire que Parrot était bon pour les langages dynamiques, mais je n'ai pas entendu parler de tous La langue utilisée est celle-là. Dois-je inventer la mienne ? Est-ce que LLVM compte comme une VM contre laquelle je devrais compiler, ou est-ce que c'est aussi difficile que x86 ?

Par ailleurs, quels sont les avantages et les inconvénients des VM basées sur la pile par rapport à celles basées sur le registre ?

Il serait important de disposer d'un soutien en matière de performances et d'outils. Je vais écrire le compilateur en Haskell, donc une bonne interface avec ce langage est un plus.

10voto

Reed Copsey Points 315315

La JVM (Java) et le CLR (.NET) semblent être les deux cibles les plus courantes, car ils gèrent tous deux la plupart de ces questions pour vous. Elles fournissent toutes deux des jeux d'instructions assez simples à utiliser.

Le CLR a un avantage : il a été conçu dans le but de supporter plusieurs langages dès le départ, et il est (IMO) légèrement plus facile à utiliser, surtout si vous n'écrivez pas un langage qui entre dans le "moule" original des langages initiaux ciblant ce runtime. Mono fonctionne suffisamment bien pour que je ne me détourne pas d'une cible CLR à cause de cela.

5voto

Karmastan Points 4092

LLVM offre un modèle de programmation bien meilleur que l'assemblage x86 classique. Oui, c'est du bas niveau. Mais vous n'avez pas à vous soucier de l'ordonnancement des registres ou de l'optimisation complète de vos résultats. De plus, pendant que vous écrivez votre front-end, vous pouvez profiter de son système de types pour rattraper les erreurs que vous pourriez commettre.

Cela dit, vous devrez développer votre propre couche d'exécution pour prendre en charge les parties "dynamiques" de votre langage. Rien que pour cette partie, j'aurais tendance à m'en tenir au CLR.

2voto

delnan Points 52260

.NET dispose du Dynamic Language Runtime, comme l'a mentionné Reed Copsey. Mais je ne connais même pas le CLR, et encore moins le DLR - je ne peux rien dire sur l'un ou l'autre. Le LLVM devrait être plus agréable que le simple x86, mais il reste de bas niveau. Mais je ne peux pas non plus en dire grand-chose - juste quelques coups d'œil.

J'ai cependant examiné Parrot. L'idée en soi est assez géniale, et la mise en œuvre semble solide. Si je crée un jour un langage dynamique, je suis presque sûr qu'il visera Parrot. Les PIR (Parrot intermediate representation) est de très haut niveau pour une VM. Vous avez du sucre syntaxique (opérateurs ariméthiques, assignations, appeler des sous-programmes et en revenir est un jeu d'enfant, ...), vous ne vous occupez pas du nombre exact de registres mais vous en prenez autant que vous voulez et vous leur assignez n'importe quel nombre, et vous avez même des variables nommées !

Si je devais choisir, je pense que je préférerais une VM basée sur le registre. Les recherches indiquent que ces dernières échangent la taille du bytecode contre la vitesse d'exécution, ce qui me convient parfaitement. De plus, les opérations de pile trop complexes ont tendance à me tordre le cerveau lorsque j'essaie de les comprendre - les opérations basées sur les registres sont plus naturelles, je pense.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X