Fri Sep 12 13:22:50 CEST 2008
I don't have a target board at hand atm, but i'd like to test the
interaction code.. How to proceed? Let's connect the default IO to a
stack machine simulator that simulates the 3-instruction Forth.
Got it +- working, except for data stack access: this is not abstract
enough in the current tethered approach.
The simplest solution seems to be to add a 'meta' command to the
interpreter, which will load a pointer to a meta struct area. This
could then contain info about the target, without the need for more
interpreter instructions. Alternatively, this could be stored in a
per-micro specific location. i.e. the boot block.
OK.. now I'm getting ambitious.. What about turning this into a seed
for a proper machine simulator? Instead of writing a version of the
interpreter for the machine, compile the current .f code to another
machine and run that in the simulator. Might be a good idea to
converge on the standard machine model.
Let's try to separate things out a bit..
1. Reference semantics = Scheme. The pattern matching rules define
the different type signatures.
2. Machine model = stack ops + memory reference. The stack ops can
be derived straight from the macros.
So, build a function that translates a bunch of macros into a symbolic
interpreter for a stack machine with a certain word length.
What should be the goal?
* To be able to compile .f code to a standard virtual machine for
bit-accurate simulation + testing of control structures.
* Simplify this kind of simulation + generic platform-specific
simulation and porting. The idea is that if I want to compile to
a huge number of architectures, I better think about a decent
simulator/assembler architecture. It's probably best to allow for
an incremental assembler construction path: not all opcodes are
necessary to create a basic uC port. A lot of the assembler
infrastructure for PIC18 is not really used.