Vergleich ========= 1-byte virtual code: -------------------- + sehr kurzer code: 1 oder 2 bytes / opcode + arguments ~ 2.5 bytes / opcode - benötigt jump table ~ 1 kB + hat automatisch eine jump table - jump table kompliziert o progs, die helper procs im rom aufrufen, müssen trotzdem erst "gelinkt" werden. - slow ~ mcode / 10 - code-optimierung durch kombicodes führt immer zu 2-byte kombicodes mit mind. 59 cc lohnt sich ggü. 2-byte vcode im ram immer lohnt sich ggü. 2-byte vcode im rom ab ~ 6 kB vcode ;primary opcode: next: ld h,hi(vtable) 7 ld a,(bc++) 13 ld l,a 4 jp hl 4 vector: jp nnnn 10 = 38 cc ;ca. 30 opcodes können next verkürzen: (wenn sie in der primary table liegen) GVAR, IN, OUT, IVAL0, IVAL1, EI, DI, DROP, HALT, SELECT, TOR, FROMR, BOOL, RETURN, IVAL, IVALu8, NEG, CPL, NOT, SL1, SRu1, SRS1, ADDI, SUBI, GETLO, SWAPBYTES, MSBIT, JP0, JP1, JP next2: ld a,(bc++) 13 ld l,a 4 jp hl 4 vector: jp nnnn 10 = 31 cc ; secondary jump table: next: ld h,hi(vtable) 7 ld a,(bc++) 13 ld l,a 4 jp hl 4 vector: inc h 4 ld a,(bc++) 13 ld l,a 4 jp nnnn 10 = 59 cc 2-byte virtual code: -------------------- + kurzer code: 2 bytes / opcode + arguments ~ 3 byte / opcode + benötigt keine jump table - progs müssen immer erst "gelinkt" werden. - slow ~ mcode / 10 ;opcode linking: ld a,(bc++) 13 ld l,a 4 ld a,(bc++) 13 ld h,a 4 jp (hl) 4 = 38 cc verkürztes opcode-linking denkbar, wenn 1. opcode und ein set von häufigen folge-opcodes in einer page liegen. z.B. IVAL/IVALu8 + ADD/SUB/AND/OR/XOR/… ;kurzes opcode linking im 1. opcode: ld a,(bc++) 13 ld l,a 4 jp (hl) 4 = 21 cc real code: ---------- - bloated: ca. 6 byte/opcode + helper procs + fastest ~ mcode / 3 + benötigt keine jump table - progs müssen "gelinkt" werden, wenn sie helper im rom benutzen. andernfalls noch größer. (ram is tight!) + BC is free to use - return address is on VM vstack whenever a helper or function is called real code kann mit vcode kombiniert werden. helper im rom werden ggf. doppelt benötigt.