Quote:
Originariamente inviato da cionci
In effetti...
Comunque le strade da percorrere ora potrebbero essere molteplici: i dati a 16 bit rendono secondo me il parsing un filo inefficiente. Forse la dimensione migliore sarebbe 32 bit, ma ovviamente si perderebbero i vantaggi nel risparmio di spazio.
|
Non solo: si aumenterebbe anche il consumo di bandwidth, e aumenterebbero le istruzioni necessarie per estrarre i dati che servono (opcode e relativi parametri), in particolare sulle architetture big-endian.
Quote:
|
Però con l'idea di Tommo la cosa potrebbe divenire interessante, la fusione di una sequenza di istruzioni in un solo opcode a 32 bit farebbe risparmiare ancora spazio e renderebbe il tutto più veloce (ovviamente senza mescolare opcode a 16 e a 32 bit).
|
Lo faccio già.
Nella mia implementazione ho opcode a 16 e 32 bit, e alcune fanno un mare di lavoro (arrivo a eseguire gli stessi compiti di ben 4 istruzioni della vecchia implementazione).
Il modello che ho proposto non ha opcode di dimensione fissa: la dimensione è variabile, e attualmente posso avere istruzioni di 1, 2 o 3 word (quindi 2, 4 o 6 byte).
Un modello "CISC", appunto, che è il nome che ho dato a questa versione.
Altre VM, come quella di LUA ad esempio, utilizzano invece opcode a 32 bit di dimensione fissa.