World: r3wp

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

So, it looks like 3 flags, one of which may be set afterwards, and 
some ranges. Either that means some really interesting math, or a 
4096 byte lookup table :(

What's the H flag?

Half carry flag

What's that for?

set if bit 4 is set after an operation

Got it.

useless in most case (i don't manage it in my code)

It seems to matter here. Perhaps you should set it after BCD operations.

yep, i fear that

i have to handle it in all math operations

Or for that matter, you could set the reference to the lookup table 
to be the appropriate one after the initial operation. That way you 
don't need to test the flag later - the flag could be implied.

yep it's a possibility

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.