ngaro has now a native-code compiler

[Mat]

Hello,

The compiler is finished and I think again about it's integration in
retro. At first I will extend the instruction-set by the four opcodes
already described but as a result of it I foresee a small problem:

The compiler expects opcode streams in CPS form (that offers the
possibility for implementation of SSA based optimations and makes tail-
calls implicitly) ! Thus the function mode in particular of the branch
instructions is not comparable with their interpreted behaviour -

A branch target in the interpreter context is simply an offset into vm
memory where it is compiled as reference into a trace (a linear
instruction sequence traversing at least a portion of a method, a
loop, or a branching node).

A little example (vm.c):


/* trace for compiling 0; if accumulator a = 0 */

int cVM_ZERO_TAKEN = label
tba
pldb
retc

...

cVM_ZERO_EXIT: biza (cVM_ZERO_TAKEN) CNEXT;


CNEXT ist the replicated-switch loop of the compiler, compilation ends
with a RET opcode.

Mnemonics:

biza (target) -
Branch If Zero A: branch to target if accumulator A = 0

pldb -
PuLl value from top of data-stack D into accumulator B

tba -
Transfair value of accumulator B to accumulator A

retc -
RETurn from subroutine and Compile trace.


So what's the best way to handle this ?
I think at first it's useful to write an assembler in retro so the
instruction-set can be extended by demand (traces can be called with
the new XOP opcode once compiled [I renamed the mnemonics a bit]). The
next step would be to rewrite the retro compiler so it generate and
call traces instead of vm-code sequences.

I think of javascript and java back-ends for the compiler also (it
would simply generates javascript (executable via EVAL) and java byte
code) whch would mean the new retro image should be run on most ports
except the NET one (don't know if it's possible to generate and
execute CLI byte code at runtime).

What's your opinion ?

[Charles Childers]

It looks good.

I haven't had a chance to consider the issues you've raised, but I do like the simpler design.

I've forked the repo on github and have some patches there that you may find useful (support for MacOS X [symbol naming stuff in the assembly], file permissions, and building apart from the main source tree.)

-- crc

[Todd Thomas]