Il lavoro di una VM è eseguire codice arbitrario. (Metti da parte i pensieri della JIT per un secondo, stiamo solo parlando della pura VM). Come ti aspetti di compilare programmi arbitrari in bytecode per la tua VM? Devi avere un set di istruzioni. Quel set di intruction deve funzionare su qualcosa. Se parli di variabili che operano direttamente da un linguaggio di alto livello, assicurati che sia possibile, ma in realtà non è una VM. È solo un interprete. Un interprete può essere simbolico (cioè può lavorare sui nomi) e può essere di alto livello. Può operare su nodi AST o su testo puro. Ma una VM generalmente è di livello più basso, emula una CPU semplice e il bytecode stesso è una forma di linguaggio intermedio. Quindi puoi distribuire i tuoi programmi in forma bytecode che ti dà un certo livello di protezione (anche se in Java e nel mondo .NET non quanto la VM fosse un po 'più basso).
Il lato negativo degli interpreti di alto livello è che fanno un sacco di lavoro simbolico ogni volta che esegui il programma. La forza di una VM arriva quando combinata con il compilatore. Prendi C # per esempio. Certo, puoi scrivere un programma per interpretare C # ad un livello elevato (l'ho fatto per Parrot VM anni fa), ma l'esecuzione è molto più efficiente se fai un po 'di lavoro in anticipo come le variabili di compilazione fino ai registri o allo stack operandi. Quindi il tuo programma diventa molto più denso di AST, ed è di nuovo, opportunamente rappresentato come denso codice byte.
Si definiscono le operazioni virtuali più semplici o più vicine alle istruzioni reali da compilare in tempo reale con il real eseguibile nativo da parte di JITter, noto anche come Just in Time Compilation. Più semplici sono gli op, più efficiente è l'implementazione di JITter.
Inoltre, in modalità non JIT (pura operazione VM) se si compilano gli accessi simbolici in basso per registrare o impilare gli operandi, è possibile migliorare le prestazioni della VM assicurandosi che l'area del registro centrale sia memorizzata nella cache. Se le variabili sono in tutto lo heap e si sceglie di operare direttamente su di esse, si perde l'efficienza della cache. Con un registro VM potremmo progettarlo con registri fissi, o registri virtuali illimitati, ma in ogni caso, un allocatore li mapperà a registri fissi che sono impacchettati in un segmento contiguo di RAM che speriamo si adatti a meno linee di cache L1 e guadagna prestazioni per località spaziale.
Ma è possibile una VM simbolica di alto livello che opera direttamente sulle variabili. Ecco un paio di alternative.
VM A - Simbolico:
newglobal "count"
add "count", 1
VM B - Registra (trasferimento di memoria):
mkglobal "count"
move $R1, "count"
inc $R1
Il vantaggio di VM B è che gli opcode sono molto vicini o facilmente traducibili a processori live reali, poiché la maggior parte dei processori non consente operazioni su variabili di memoria e richiedono di caricare la variabile in un registro o su uno stack. La squadra investigativa avrà molto meno da fare. Con VM A, l'operazione add è in realtà una grossa operazione di aggregazione che deve essere compilata in singole operazioni native.
Per un semplice confronto con i due approcci, studiare Perl5 e studiare bytecode C # /. NET. Mentre è possibile compilare Perl5 su un bytecode, non è la forma predefinita di esso. Perl fa davvero più interpretazione simbolica di un AST in memoria. Ecco perché è stato un grande cambiamento architettonico quando abbiamo scritto Parrot per Perl6, anche se non sono convinto che fosse la decisione giusta per quel linguaggio.