on the HAL-9000

[David Jeske]

On Mon, Oct 12, 1998 at 06:07:41PM -0700, RE01 Rice Brian T. EM2 wrote:
> Right. And those imply semantics (more complex than the example I
> mentioned) partially governed by the hardware: the 'background', if you
> will, to the semantic meaning of the program as the user would see it.
> The semantics would be specified, in a total sense, by a 'run-time
> scheme' a.k.a. the operating system.  The choice may also be between
> recording a piece of calculated data once a procedure is done or
> re-executing the procedure to re-create the data as a 'virtual store'
> when execution time is much faster than disk access time, or other
> issues.  

Agreed.

> My point was that semantical definitions could be easy to come
> by, freeing the user to focus on the issue-independent part of the
> application, while the abstraction mechanism would allow the user
> (hopefully quick) access to the issues governing how the code-generator
> writes the code.

I'm mostly with you here. I'm a little fuzzy on what your thinking in
the first sentence.

> Well, we could make a code-generator that creates different types of
> code output.  One couldn't argue well against having two distinct
> code-generators in run-time, say if making code for a machine with two
> kinds of processors.  Similarly, if parts of the code-generator were
> designed for different types of semantic-level reflection on the code
> for efficiency, or simply that a code-generator with a more
> 'down-to-earth' language interface added on would probably work.
> However, the cases where this would be needed, since no code sequence
> exists alone (i/o overhead, ...), would be where the code-generator
> would match the code sequence with 'function calls' of a sort (as in a
> debugging process or a 'calculator' process, i.e. interaction with small
> events).  Hopefully, most aspects would be 'weaved' into the code
> statically before the code-generator 'sees' it: equivalently, the
> code-generator at some point in the pipeline could make a persistent
> compacted intermediate form to operate on incrementally on successive
> optimizations (for code development).
> Obviously, we should elaborate on this issue (I already have a few
> ideas), possibly by classifying (in a fuzzy way) the areas and
> dimensions of this 'computational manifold' as it were.  (manifold =
> space).

> ok.  Let's try to put together a holistic model.

Okay. I propose we create a simple 'sample problem' that we are going
to describe at a high level and translate to a low level. If we can
come up with a holistic model for performing this translation which
will allow us to add new code generation constraints and optimization
aspects, I'm all for holistic.

I'll think on this more and see what I can come up with.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net