Stack di codice byte rispetto a tre indirizzi

Question

Quando si progetta un interprete di codice byte, in questi giorni c'è un consenso sul fatto che sia lo stack o tre formato di indirizzo (o qualcos'altro?)? Sto guardando queste considerazioni:

1. Il linguaggio oggettivo è un linguaggio dinamico abbastanza simile a JavaScript.

2. Le prestazioni sono importanti, ma la velocità di sviluppo e la portabilità lo sono per il momento.

3. Pertanto l'implementazione sarà strettamente un interprete per il momento; Un compilatore JIT può venire più tardi, risorse che lo consentono.

4. L'interprete sarà scritto in C.

Answer 1

Dai un'occhiata all'interprete di bytecode OCAML: è uno dei più veloci del suo genere. È praticamente una macchina da stack, tradotta in un codice threading al caricamento (utilizzando l'estensione GNU calcolata). Puoi anche generare un codice thread-simile, dovrebbe essere relativamente facile da fare.

Ma se stai tenendo a mente una futura raccolta JIT, assicurati che la tua macchina da stack non sia davvero una macchina da stack a piena persona Per tradurre il tuo bytecode "stack" in una forma a 3 indirizzi e poi in una SSA.

Answer 2

Leggi L'evoluzione di Lua e L'implementazione di LUA 5.0 Per come Lua è cambiato da una macchina virtuale basata su stack a una macchina virtuale basata sul registro e perché ha ottenuto prestazioni facendolo.

Answer 3

Esperimenti realizzati da David Gregg e Roberto Ierusalimschy hanno dimostrato che un bytecode basato sul registro funziona meglio di un bytecode basato su stack perché sono necessarie meno istruzioni bytecode (e quindi meno overhead di decodifica) per svolgere le stesse attività. Così Il formato a tre indirizzi è un chiaro vincitore.

Answer 4

Non ho molta (non proprio) esperienza in questo settore, quindi potresti voler verificare alcune delle seguenti persone (o forse qualcun altro può correggermi ove necessario?).

Le due lingue con cui lavoro al giorno d'oggi sono C# e Java, quindi sono naturalmente inclinato alle loro metodologie. Come la maggior parte delle persone sanno, entrambi sono compilati al codice byte ed entrambe le piattaforme (CLR e JVM) utilizzano JIT (almeno nelle implementazioni tradizionali). Inoltre, immagino che i nervosismi per ogni piattaforma siano scritti in C/C ++, ma non lo so davvero.

Tutto sommato, queste lingue e le loro rispettive piattaforme sono abbastanza simili alla tua situazione (a parte la parte dinamica, ma non sono sicuro che questo sia importante). Inoltre, dal momento che sono linguaggi così tradizionali, sono sicuro che le loro implementazioni possano servire da una guida abbastanza buona per il tuo design.

---

Con ciò, so con certezza che sia il CLR che il JVM sono architetture basate su Stack. Alcuni dei vantaggi che ricordo per basati sugli stack vs basati sul registro sono

1. Codice generato più piccolo
2. Interpreti più semplici
3. Compilatori più semplici
4. eccetera.

Inoltre, trovo che lo stack sia un po 'più intuitivo e leggibile, ma è una cosa soggettiva, e come ho detto prima, non ho ancora visto troppo codice byte.

Alcuni vantaggi dell'architettura basati sul registro sono

1. Meno istruzioni devono essere eseguite
2. Interpreti più veloci (segue il n. 1)
3. Può essere più prontamente tradotto in codice macchina, poiché la maggior parte degli hardware all'ordine sono basati su registro
4. eccetera.

Naturalmente, ci sono sempre modi per compensare gli svantaggi per ciascuno, ma penso che questi descrivano le cose ovvie da considerare.

Answer 5

Se hai in mente Jit, allora bytecodes è l'unica opzione.

Nel caso in cui tu possa dare un'occhiata al mio tocroscritto: http://www.codeproject.com/kb/recipes/tiscript.aspx e fonti: http://code.google.com/p/tiscript/