r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[rebcode] Rebcode discussion

Steeve
20-Feb-2007
[1731x3]
currently a rebuild the parser to generate rebcode instead of rebol 
instructions
*currently i
so i don' t use set block anymore ;-)
BrianH
20-Feb-2007
[1734]
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.
Steeve
20-Feb-2007
[1735x2]
i agree
i add this to my to-do list
BrianH
20-Feb-2007
[1737]
It also occurs to me that you could assemble your own code and modify 
the code blocks at runtime to make lookups unnecessary.
Steeve
20-Feb-2007
[1738]
but there's some difficulties toing that in real time
BrianH
20-Feb-2007
[1739]
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.
Steeve
20-Feb-2007
[1740x2]
*doing that
if i concatenate code  at the end only (append) the previous branch 
offsets should not  be disturbed ?
BrianH
20-Feb-2007
[1742]
How much memory does this machine you are emulating have?
Steeve
20-Feb-2007
[1743x3]
64 Ko
Z80 can only manage 64 Ko of ram at once
but there is a sort of memory mapper
BrianH
20-Feb-2007
[1746]
How much address arithmetic is common when doing indirect branches 
and calls, and can you reverse it using flow analysis?
Steeve
20-Feb-2007
[1747x3]
hum i don't understand
adresses are on 16 bits
so Z80 can jump anywhere in 64 ko space adressing
BrianH
20-Feb-2007
[1750]
Are the Z80 opcodes fixed or variable length? If variable, are real-programmer 
tricks like branching into the middle of an opcode common?
Steeve
20-Feb-2007
[1751x2]
variable length
and yes it is common to branch in the middle of opcodes, we can't 
predict that by a static analysis
BrianH
20-Feb-2007
[1753]
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.
Steeve
20-Feb-2007
[1754]
yes and what is the question ?!?
BrianH
20-Feb-2007
[1755]
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.
Steeve
20-Feb-2007
[1756]
agree, for me it's possible only for direct jumps
BrianH
20-Feb-2007
[1757]
You don't even have to use label statements if you have 2 blocks, 
one full of references to the other.
Steeve
20-Feb-2007
[1758x3]
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
BrianH
20-Feb-2007
[1761]
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.
Steeve
20-Feb-2007
[1762]
hmm...
BrianH
20-Feb-2007
[1763]
It would mean a 64K element BRAB block for every 64K set of memory, 
in addition to the size of the generated code.
Steeve
20-Feb-2007
[1764]
hurg !!!
BrianH
20-Feb-2007
[1765]
You can't run REBOL on a cell phone, you know. Everything else has 
plenty of RAM :)
Steeve
20-Feb-2007
[1766]
yes but it's not ROM but RAM, and evil programms can rewrite opcodes
BrianH
20-Feb-2007
[1767]
So, you can keep track of which areas of RAM have code in them and 
fix up the rebcode offsets when they are modified.
Steeve
20-Feb-2007
[1768]
yes Brian, all is possible ;-)
BrianH
20-Feb-2007
[1769x4]
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.
Steeve
20-Feb-2007
[1773]
yep, i follow u
BrianH
20-Feb-2007
[1774]
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.
Steeve
20-Feb-2007
[1775]
yes, i agree
BrianH
20-Feb-2007
[1776]
If you generate it as you go along, the rebcode will be generated 
in the order that it is executed.
Steeve
20-Feb-2007
[1777]
it's the case currently
BrianH
20-Feb-2007
[1778]
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.
Steeve
20-Feb-2007
[1779]
hmmm
BrianH
20-Feb-2007
[1780]
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.