World: r3wp

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.

yes, i agree

If you generate it as you go along, the rebcode will be generated 
in the order that it is executed.

it's the case currently

If you keep the Z80 memory in a binary! and make changes to it, whenever 
code at an offset already covered by the BRAB block is modified you 
would change that offset in the BRAB block to the default and mark 
the associated section of the rebcode as free. That way the next 
time you branch to that offset it would retranslate the Z80 to rebcode 
and put that rebcode in the first free spot big enough. You could 
even break up your code into blocks of around the same size and branch 
between them, to reduce fragmentation.

hmmm

You will likely have some rebcode that corresponds to the same areas 
of Z80 memory more than once, but memory is cheap on every platform 
REBOL runs on, particularly compared to a Z80.