World: r3wp

the new rebcode version, is several times faster than the old, i'm 
happy !,  and I did not convert the video emulation into rebcode 
yet  , so ,   I think that we will be able to play in a screen much 
larger while keeping fluidity.

i could share my work, is the Altme Filesharing  working ? i think 
not

A direct interpreter, or I guess a tokenized interpreter using the 
original opcodes as tokens, which amounts to the same thing. Interesting. 
I suppose that would be simplest way to do it, and a threaded interpreter 
would be a little hard in rebcode because of the relative branches. 
Good job!

I notice that your example doesn't adjust the program counter - I 
assume that these adjustments are performed by your real code.

yeah it was a sample, my code is a little more complex

Your new version also deals with the too-many-words backwards-compatibility 
problem that the old approach had, by just having words for opcodes 
rather than addresses. It should also have much less memory overhead 
than my compiled suggestion, and not require generating the rebcode 
of the interpreter - it is probably hand-codeable.

Are all opcodes distinguishable by a single byte, or do you have 
a more complex instruction decoding process?

current state of my work http://perso.orange.fr/rebol/code.r

op-code may be on several bytes

i use several brab in sequence

if needed

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.