World: r3wp

Several branches for every instruction, but probably optimizable 
on a special-case basis. Definitely slower than compiled rebcode, 
but much less complex and without the compiler overhead, so perhaps 
not that much slower. Much more compatible with self-modifying code. 
Also likely more compatible with JIT-compiled rebcode when that happens. 
Some code-generation on your interpreter, but mostly hand-coded. 
Overall, nice.

Your VM is single-instance right now, but that won't be a problem 
until R3's threading. For now, multiple interpreters can be in different 
REBOL processes. I don't know enough about what you are interpreting 
to know whether that matters :)

mostly Game roms

they don't need multi trheading

Probably not, then. You might want to wrap this all in a context 
statement to capture the global variables you're using.

currently i'm looking for a good implementation of DDA opcode (Decimal 
adjust for BDC numbers)

quite difficult

*BCD numbers

BCD numbers in games?

yes for displaying score or other human readable numbers

That platform has BCD-based output opcodes? Surprising - most use 
integers and string conversion.

i found one that uses a look-up table of 4096 entries... little big

yes but addition and substractions are performed on char! (byte)

so, this instruction is used to addapt the result in a bcd form

for example if you add 06h and 04h, you get 0Ah which is the correct 
result in byte form, using DAA after such addition, convert the result 
into 10h which is the correct result in BCD form

DDA operates on a per-byte basis?

yep

DAA instead of DDA (made a mispell)

How does it handle out-of-range values?

it sets a flag which we calls carry (like the T flag in rebcode)

I would think a pickz on a 256-byte binary would do for a lookup 
table, putting a flag value in the invalid slots. Then you could 
react to the flag afterwards.

yes but it's a little more difficult

DAA react diffenrently after an addition or a cubstraction

*substraction

256 entries for the lookup table is not enough

More than one lookup table, depending on circumstances?

4096 entries are requested to cover all possiblities

Perhaps some math to do much of the work would be preferable.

finally, 4ko, is not so huge

You are right there...

*4 kb :-)

I forget (and don't have rebcode installed on this PC), what happens 
if you pick out-of-range in rebcode?

don't konw , never occured

i test

** Script Error: Out of range or past end
** Where: f
** Near: pickz a b 10

quite good

Not for what I was thinking. I was trying a multistep process where 
the need for the next step is determined by whether the pick of the 
earlier succeeded. I suppose the same could be accomplished by math, 
but a pick would have allowed smaller lookup tables.

and using past?

How does the DAA react differently after an add or a sub? Could you 
simplify things by combining the add/sub and the daa into a larger 
logical opcode? It occured to me, looking at your code earlier, that 
you could combine strings of opcodes that didn't include writes to 
memory into larger virtual opcodes, to cut down on interpreter overhead 
when not necessary.

i see, but DAA not follows sub or add opcodes, he can act severall 
opcodes later

It would mean more branch tables or some branch index arithmetic, 
but the interpreter could be made much faster in certain cases.

Z80 just remember if the last math operation was an add or a substract

What is the effect of the add/sub that affects the DAA? Is it some 
flag?

yes a flag, but this flag is not visible

so in rebcode , i will have to manage this trick by myself, with 
seting my own DaaFlag after a sub or an add

Sorry, that answers my question. Perhaps putting the DAA implementation 
in the blocks of an either statement on that flag would lessen the 
lookup overhead.

*by setting

I'm curious as to what the effect really is. Perhaps a positive/negative 
issue?

you can sse the trick here http://www.zilog.com/docs/z80/um0080.pdf

*see