World: r3wp

Are you doing a compiler or an interpreter? A compiler would be faster, 
but would require you to translate branches.

it's an hybrid way

i try to do the two things

A JIT compiler, perhaps?

sort of like a JIT ?

hehe

first i parse Z80 opcodes and execute them step by step, then they 
are concatened to build sub-routines and cached, if sub-routines 
are mantory another time, then i call cached sub-routines instead 
of reparse the opcodes.

*mandatory

(requested is better)

Do you do basic block analysis of the source opcodes to determine 
where the subroutine boundaries are? For that matter, does the Z80 
have indirect branches?

;-_-

Sorry, I don't speak IRC.

yes indirect branches exist

but it's not a problem, the management of branches is done in real 
time, it's in a stack, so i can manage fixed as indirect branches.

How common are they? Can you analyze them to determine their destinations 
to convert them into branches or calls?

all branches are converted into call

difficult to explain with my bad english

Call of function or continuation? (Sorry if your English doesn't 
include computer-science terms)

Meaning, does the call return?

when i seek a Z80 branch opcode (direct or indirect), i stop the 
current rebcode function construction and i build new one for the 
folowing opcodes

so each rebcode function (routines) must return the adress of the 
next branch

Continuation then.

How do you handle back-branches then?

if a routine return an unknwon adress, then the parser jump a these 
adress and rebuild a new function.

back-branches are treated in the same manner

So, no basic block analysis at all. All branches are considered non-local.

yep

Would it be too difficult to translate branches to literal offsets 
into their rebcode equivalents, as an optimization?

here you can see my first try without rebcode http://perso.orange.fr/rebol/galaga.r

i could try this as a final compilation step, perhaps

in the source you can see the concept of branches management i use

Your trick of generating words for branch targets may need changing 
when you switch to rebcode. Pre-2.7 versions of REBOL had hard limits 
on the number of words possible at once (about 8000). You might consider 
issue! values instead with a lookup table (probably a hash!).

ok

It will be a little slower. You might then return references to the 
code rather than the names.

That will cut down on lookups. Make it threaded.

i think i will implement  a cached routines cleaner (GC) ,  to keep 
in memory only routines which are frequently requested

There are some optimizations you can make to the code too, such as 
changing code like this:
    set [v1 v2] reduce [_d _e]
to this:
    v1: _d
    v2: _e

i know but i have some constraint do to my parser

anyway, with rebcode i changed my way

*due to

No block set.

i know

currently a rebuild the parser to generate rebcode instead of rebol 
instructions

*currently i

so i don' t use set block anymore ;-)

It occurs to me that you might be able to do the fixups using a compile-time 
lookup table, or perhaps translating addresses to label statements.

i agree

i add this to my to-do list

It also occurs to me that you could assemble your own code and modify 
the code blocks at runtime to make lookups unnecessary.

but there's some difficulties toing that in real time