CMUCL Native CLOS

[Jonathan Bachrach <bachrach@ICSI.Berkeley.EDU>]

Rob, comments on comments on comments...

    Hmmn.  I'll ponder this.  My first reaction is that it might be better to
    have the class be a generally-reasonably-small integer class ID, with an
    indirection through a class table to find the object.  This would
    potentially allow the class ID to be compiled as an immediate constant, and
    would work somewhat better for caching schemes, since class IDs would be
    more dense than class pointers.  

The problem with having class ID's is that the dispatching code must
test to see whether the object is a builtin or a regular CLOS object.
If the object is a builtin then use the class ID else use the class
pointer.  If the representation is uniform (with all objects having
class pointers), then no such test is necessary.  This seems crucial
to me for efficient CLOS, because the class is accessed so often.

Now if you're suggesting having all classes have class ID's, then this
is another thing entirely.  It appears that this is inefficient as
well, because you always need that extra indirection.

    Also, when true 64bit machines come, you will want to put the whole
    descriptor on one word, but probably won't want to be confined to a measly
    32bit heap.  If the class ID is more densely encoded, then you can grab a
    high chunk of say 20 bits to hold it.

Personally, I'm not so concerned with a measely 32bit heap.  I would
rather penalize people for using >32bit addresses than penalize
everyone for all accesses to objects.  Furthermore, I'm confident that
accessing the upper 32bits of a 64bit word will be much faster than
accessing the upper 20bits.

    A key question here is which (declare (fixnum i)) would be equivalent to.
    It would presumably be the former, which would make existing programs
    reasonably efficient, but would also make them non-generic.

Actually, I think that (declare (type fixnum i)) should be equivalent
to (declare (subclass fixnum i)) because this is consistent with
CommonLisp typing.  But going along the lines of what you are
suggesting about not having fixnum subclassable would guarantee that
this would be implemented efficiently.  I'm not exactly sure what your
worries were about non-generic arithmetic.

    Defining hash-tables as classes makes a great deal of sense, since even as
    a CL primitive, the functions are "generic" due to different kinds of
    hash-tables.  As for lists, the Lisp implementation is over-constrained.
    You don't really have lists, you have conses.  If you wanted a general list
    class, you would be better off making a totally new one, and making the
    generic sequence functions work on it.  If vector operations were generic,
    that would be easy.

I agree with you here.  

I am incredibly excited about your ideas on the SELF optimization
techniques.  This sounds like an amazing idea.  I'm going to read the
SELF papers more carefully.  

I have a few questions for you.
Are their any immediate plans for implementing the
dynamic-extent declaration for declaring &rest args on the stack as
well as other local variables?  

Are there any immediate plans to implement a multiprocessing facility
that would allow multiple threads within one lisp process?

Finally, are there any immediate plans to port CMUCL to the new $5000
34-SPEC-Mark HP snake machine?

-- jonathan