World: r3wp

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 :)

yes but it's not ROM but RAM, and evil programms can rewrite opcodes

So, you can keep track of which areas of RAM have code in them and 
fix up the rebcode offsets when they are modified.

yes Brian, all is possible ;-)

You can even implement memory protection by filling the areas of 
the BRAB block that correspond to inappropriate areas of RAM with 
branch offsets to error-handling code.

That could be the default value to fill the BRAB block with. For 
that matter, if the error handling code directly follows the BRAB 
block you can use the value 0 to fill the BRAB block with by default.

You can even do this incrementally by filling in the code block as 
you go along and fixing up the offsets in the BRAB block as you generate 
the code that they point to..

The code generator can be your default code too, so code will get 
generated on the fly.

yep, i follow u

There is no reason that the generated rebcode need be in the same 
order in its block that the original code is in its context. The 
BRAB block adds a layer of indirection, making the memory virtual.