World: r3wp

No need to follow CPU internal execution patterns when you aren't 
a real CPU.

thats why the lookup table have 4096 entries

get the correct offset following the content of accumulator before 
math operation

then retrive the corrected BCD result using the byte AFTER the math 
operation

hum not sure about what i said, i have to think ... more

the problem with the Half carry flag is that you must compare the 
data before with the data after

you can't just test the 4th bit of the resulting data

5th sorry

So, you do BCD arithmetic by using binary arithmetic on BCD values 
and then using DAA to fudge the data afterwards?

i fear it will slow the math operations more than expected

You can improve the overall speed elsewhere by combining strings 
of operations between writes to memory.

it's not me who do that but Z80 :-)

combining...

No, you can do it. The main reason that you have to branch back to 
the beginning of your interpreter at every step is because the next 
step might have been modified by the previous. You can speed that 
up though, by realizing that the only statements that really need 
that paranoia are memory writes and branches - other opcodes can 
by combined in your interpreter, like looking more than one move 
ahead in chess.

yes but combining operations need more tests so it will decrease 
overall performance. i do'nt see how i can do that without consumming 
more times to compile series of opcodes

It would require a more complex state machine, but since you wouldn't 
be starting over with every opcode it would execute less tests and 
branches per step than not combining. Think of combining opcodes 
as a kind of loop unrolling.

It would be not that different from your existing multi-byte opcode 
process, just for more opcodes.

i see

so in fact it could be performed by a static analyse of the code 
before ther real execution, and will result in addition of new byte-opcodes.

yep

You could even generate more of your interpreter by using more interesting 
macros, which would cut down on the programmer overhead of the increased 
number of states in your state machine.

like what ?

like iterative macros

currently i want keep ly source readable

but after the debuguing phase, i think i could compact the code with 
more macros, i agree

Perhaps you could specify your operations in a table and then go 
through it with a dialect processor like BURG - REBOL is good at 
that sort of thing. Then you could generate your interpreter from 
that table.

BURG ? sort of beer effect ?

No, BURG is a tool used to generate backends for compilers from a 
processor specification dialect.

:-)

It's for compilers written in C. I think you could do something like 
BURG in a few lines of REBOL though :)

Plus the input data, of course.

or you could add a a ReBurg function in the Rebol VM , to do that 
in my place :-)

don't knwo Burg dialect

*know

The dialect you would use probably wouldn't look much like BURG, 
since you are generating an interpreter.

Your generator would probably act a lot more like a peephole optimizer.

BTW, why rebcode thread is not on rebol.net ?

Few of the groups are. If I had to guess, it would be to avoid the 
reputation of vaporware. It has been a while since they have done 
a version of REBOL with rebcode, and it had some significant shortcomings. 
There may be no reason, though.

BrianH i test some changed with rebcode on my video emulation of 
the MSX, it seems than some native rebol instructions are more faster 
with image handling than rebcode

for example i can copy one image to another one with change instruction 
but  not using rebcode

rebcode can only handle byte series

Yeah, rebcode just cuts down on interpreter overhead, but since its 
operations are a bit lower-level they aren't necessarily as fast. 
For simple operations it can be much faster, but natives are just 
that, optimized native code.

Fortunately you can call the natives with the apply opcode and get 
the best of both worlds.

fortunatly :)

my interpreter  will be faster if any math operations could act on 
char (one byte)

and if more flags was handled

That isn't always the case with modern processors - some work faster 
with integers. I agree on the flags though, in your case.

could the T flag be set after a locial operation like AND ?

very usefull to test if a bit is set

*after a logical operation