holistic code-generation model

[RE01 Rice Brian T. EM2]

>Perhaps you misunderstood what I meant when I said example. I want to
>explain every single transition of the code, until it finally becomes
>something which can run machine instructions, including how the
>optimizations we can come up with will work.
>
>I was thinking more along the lines of an example where we describe a
>matrix operation to combine two datasets into a third, or code for a
>doubly linked list, and operations on that list. Where we start with
>the proposed high level description, and my hand perform this
>'holistic code-generation' on that high-level description.
ok. So we'll work with the code-generator as an executable function
itself.  I don't see that as being very interesting at first glance, but
ok.  We could start with Xerox's aspect-oriented model of a pipeline
receiving the core language set with aspect declarations separate.  The
parser itself could be located before or after the weaver, though i
prefer actually parsing the code 'interactively'- within the editor
window as the user types in code.  This allows immediate syntax-checking
and a lighter-weight code-generation thread.  So, the aspect weaver
creates a control/data-flow graph which may or may not be
hardware-independent (unless abstracted, since the user could have
already restricted his/her programming context before-hand to
machine-dependent issues).  The compiler/optimizer, which has been
custom-made for the particular environment**, performs the appropriate
transformation into a first-run relatively un-optimized piece of code
(as a thread or coroutine or subroutine), which has the appropriate
'sugarings' to allow run-time profile data to be collected for later
optimization.  The run-time meta-data (memory-management parts of code
in memory) will be updated appropriately as well.  Basically, I believe
everything hinges around the customizability of the code-generator for
various run-time schemes.  Perhaps most major changes by the user to the
run-time scheme could be made simply by creating a new process and
porting over the necessary elements dynamically, meanwhile preparing to
'dump' the old process into the persistent store (or the essential
definition of the old environment).

**This code-generator's modularity in terms of making out of C-functions
may be rather limited, due to the natural desire to heavily optimize
this routine for the Tunes environment, resulting in a 'blurring' of the
inter-procedural boundaries, as it were.  However, stages may still be
rather enticing, due to machine-dependent intermediate forms which,
though partially-optimized, may still allow the opportunity for the
run-time to modify them, allowing quick turn-around for the 'no-kernel'
system where every procedure holds some responsibility for co-operation
and performance of the system.

I realize, of course, that I should go into much greater detail on this.
 It should suffice as a preliminary, however.