World: r3wp

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

As long as you don't change the length of the code blocks any offsets 
would still be valid and the location in memory of the data underlying 
the code blocks wouldn't change, lowering the chance of a crash.

*doing that

if i concatenate code  at the end only (append) the previous branch 
offsets should not  be disturbed ?

How much memory does this machine you are emulating have?

64 Ko

Z80 can only manage 64 Ko of ram at once

but there is a sort of memory mapper

How much address arithmetic is common when doing indirect branches 
and calls, and can you reverse it using flow analysis?

hum i don't understand

adresses are on 16 bits

so Z80 can jump anywhere in 64 ko space adressing

Are the Z80 opcodes fixed or variable length? If variable, are real-programmer 
tricks like branching into the middle of an opcode common?

variable length

and yes it is common to branch in the middle of opcodes, we can't 
predict that by a static analysis

I mean, to the middle of opcodes, not from. The real-programmer trick 
is to treat the latter portion of an opcode as if it were a different 
opcode, just because it has the same bit pattern, or worse yet, branching 
into the middle of static data.

yes and what is the question ?!?

I was seeing how difficult it would be to do a full-program compilation 
to a single rebcode block, with label statements at every branch 
destination.

agree, for me it's possible only for direct jumps

You don't even have to use label statements if you have 2 blocks, 
one full of references to the other.

but in my example source, there is 80% of direct jumps

agree BrianH

my parser was just a proof of concept, i agree there is a lot of 
optimizations to do

If you are really evil, you could fill a BRAB block with the offsets 
of every Z80 operation into the offsets of their equivalent rebcode 
operations and turn every branch into an address calculation, a BRA 
to a label before the BRAB, then the BRAB.

hmm...

It would mean a 64K element BRAB block for every 64K set of memory, 
in addition to the size of the generated code.

hurg !!!

You can't run REBOL on a cell phone, you know. Everything else has 
plenty of RAM :)