Fri Apr 24 08:54:27 CEST 2009
Cleaning up forth-begin code to make it parameterizable.
What i really want is a sort of intermediate form to display Forth
files in a similar way to the 'compositions macro. Basicly, .f
parsing should get rid of all the parsing words, but leave the rest
intact. This will probably expose some hairy bits..
I'm getting rid of the rpn-map-target-identifier parameter: let's
stick to '(target) namespace in the forth-begin macro. If not,
later simply pass the namepspaces to the forth-begin macro.
Ok.. time for the final test.
compile: unbound identifier in module in: asm/qw
This is defined in op/asm.ss
Need to rename things:
jump-cfg doesn't really compile cfg: just a list of list of chunks
anyways, in the mean time i fixed the command line interface to the
compiler. it's again possible in snot to simply type forth code and
have the resulting assembly code displayed.
/home/tom/staapl/staapl/comp/unit-jump-cfg.ss:225:6: opcode ``cw'' won't match opcode with same name.
/home/tom/staapl/staapl/pic18/unit-pic18.ss:599:14: opcode ``exit'' won't match opcode with same name.
/home/tom/staapl/staapl/pic18/unit-pic18.ss:600:4: opcode ``exit'' won't match opcode with same name.
/home/tom/staapl/staapl/pic18/unit-pic18.ss:609:4: opcode ``save'' won't match opcode with same name.
seems like there are different instances of the asm? objects due to
unit instantiation.. let's make sure they are linked by putting them
in a separate unit.
now.. instead of rushing to a maybe solution, is there a better way to
the problem is that (asm: foo) produces different results depending on
wheter it is executed inside a unit or outside.
i don't see a way to fix this without telling the instantiation
process to share instances..
let's test this.