UVM Architectures

[Bill House]

John Wood wrote:
>
>May I add that if this UVM is actually "Universal" - it should be 
>targetable to an ultimately universal range of processors.  
>
This is an interesting idea, but I wonder how omniscient we can really be.
Today, we have basically 2 chip architectures -- CISC and RISC, and both of
these may be configured in parallel computer architectures.  As an initial
goal, I think that a design that can accomodate CISC, RISC, and parallel
architectures of both, is good enough to be very useful. 

I'm not actually arguing against an abstract VM model for any possible
processor, I'm just suggesting that either a) new processors will resemble CISC
or RISC, or b) new processors will be completely different. In the case of a),
we simply rev the spec (if necessary). In the case of b), we probably don't
have enough information at this time to make informed design choices, so
whatever we come up with runs the risk of being off the mark. 

Rather than worrying about exotic chip architectures, I'd rather see us
concentrate on the collection of programming models the UVM will support. For
short list of topics that must be worked out:

	Scoping
      Types
	Closures
	Continuations
	Numbers
	Call semantics
	Dispatch semantics
	Return semantics
      Error/Exception handling
      
The issue is that each supported language will need a set of primitives that,
taken together, encompass the semantics of its programming model. Some features
are mutually-exclusive -- static-typing vs dynamic-typing, for example, as well
as lexical vs dynamic scoping. Data representation is also a problem,
paticularly since languages call for different numeric packages. 

All of this comes to bear when you start talking about the UVM running a
collection of objects written in different source languages -- it's not just an
issue of having the right function calls to implement method dispatch. What
happens when a BASIC procedure calls a CL function and  a runtime error occurs?
It may well be that the UVM needs to establish its own way of handling certain
things (like exception handling) and then making all supported languages
conform to those semantics. This may be viewed as a Bad Thing, but it may be
the only way to get somthing useable.

Of course, one way to avoid the thornier issues is to consider each language to
be running on its own virtual VM, with the UVM being more of a VM factory than
an actual VM. Then, normal IPC (COM, CORBA, whatever) can take care of calling
semantics among virtual VMs, and we can ignore  questions like "how do I return
multiple values to a BASIC caller?"

Bill House
--
http://www.dazsi.com
The views expressed are mine alone,
unless you agree with me.