CORE CODE!

[Dr. J. Van Sckalkwyk (external)]

Dear Raul

> I'd be interested in knowing why you factor out "meaning," I couldn't
> get the concept of any of these memory regions from your post.

Probably sloppy language on my part. The basic idea is that if you 
have a "variable" (eg fred) it has an attached "value" or "meaning". 
The value is a 32 bit number that can be _any_ one of the primitive 
data types. All references to "fred" in our interpreted language are 
simply pointers to the location in memory that contains this 
value. The basic idea is something like this: (adopting an arbitrary 
syntax that will probably serve to confuse you even further - sorry)!

Set up value of "fred" by:

> Set fred' [This is the value of fred]'     <send message>

or perhaps

> Set fred' 12345 <send message>

or 

> Set fred' T <send message>


and then obtain the value of fred by:

> fred  <send message>


Where the interpreter encounters "fred" (actually the pointer to the 
value of fred) and returns this value on the stack.

> Moreover, I'd tend to prefer an independent stack for each primitive
> data type, and in addition to basic instructions (dup, add, ...) for
> each stack, you need a complete set of movement instructions (e.g.
> copy from integer stack to fp stack, copy from program stream to
> character stack (do we want to bother with chracter stack?)), as well
> as a set of instructions for manipulating arbitrary data structures
> which mix data types (e.g. "memory").

This may have merit, but sounds awfully complex to me. Do you think 
that your approach (outlined above) will have major performance 
benefits?

> Um.. I think that it's a virtue to minimize data movement.  However, I
> expect (hope) that rather than use the "bank of registers" which wind
> up having complicated multi-level cache designs, it will be
> conceptually simpler to build a set of well-designed stack
> manipulation instructions.

Agreed

Bye, JVS<