[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What to do next



In general I agree with you.  However let me point out:
  1) that you can simplify MV's to the point that implementation is 
trivial.  All you have to do is require that the caller of a function
never asks for more MV's than there really are.  (In particular, that
he never asks for MV's when there aren't any.)  This handles the most
useful cases.  Certainly it handles the case of calling system functions
that return MV's.  Then you require only a couple of primitives, 
probably MV-SETQ and MV-BIND.  You certainly do not do MV-LIST (because
you can't) nor MV-CALL.  The result is that you can implement MV's
by putting the values in the AC's or in global variables.  No 
additional mechanisms are needed.  I believe this is the right thing
to have done in the first place.  (Indeed I think the whole subset
is probably going to be more useful than the real language.)
  2) we do have a compiler that is probably about as portable as
you are going to get.  We use CMU's Spice Lisp compiler.  It produces
code for a stack-oriented microcoded machine.  We transform this
into code for a register-oriented machine.  The instruction set we
use is an extended version of Utah's CMACS, the final intermediate
representation used in PSL.  It is close enough to machine code that
we produce the actual machine code in LAP.  I am sure there ae
machines that we might have trouble with, but for the ones I am
used to, a couple of days playing with LAP should allow our code to
be loaded on any register-oriented machine.  The origial Spice Lap
code could probably be loaded on any stack-oriented machine.
-------