Wed Mar 3 19:26:02 CET 2010

Staapl's substrate

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
algebraic simplifications.

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 [1] 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.

[1] http://books.google.be/books?id=Pq7pHwG1_OkC&printsec=frontcover&dq=advanced+compiler&source=bl&ots=4W91Krb-tS&sig=H7M_d8VN-MQAiInjpUshpqiwq_0&hl=en&ei=CauOS4KcKpn20gTNqvnuDA&sa=X&oi=book_result&ct=result&resnum=3&ved=0CBIQ6AEwAg