Wed Mar 3 19:26:02 CET 2010
I've been pondering a lot about the code/data issue and the
(operational) semantics of Staapl. One of the recurring themes is:
* The programmer only ever sees combinators, not machine code.
* Combinators are defined as manipulation of VM code, which is a mix
of real machine code and intermediate representations.
The same problem came back in some Haskell code I wrote for performing
The vague idea is this: you really want to only ever use combinators,
but in order to implement them they need to have a ``data base''.
In Staapl this data base is some intermediate machine code.
Combinators generate and manipulate machine code.
The thorn in my side is: why is the pseudo-machine code (QW,CW) not
separate from the real machine code? Or, is there a benefit to
combining both over a 2-phase approach where the combinators only work
on intermediate (QW,CW) code, and the peephole optimization is done
directly on that instead of by the combinators themselves?
From the perspective of  only the low-level optimizations are
relevant for Staapl. Chapter 18 talks about pattern matching for
machine idioms, which is what most of the code in the PIC18 code
generator is about. Chapter 6 talks about code generation from a
lowlevel intermediate representation (LIR) using a SLR(1) parser.