Re: CMUCL Native CLOS

[Rob_MacLachlan@LISP-PMAX2.SLISP.CS.CMU.EDU]

    From: Jonathan Bachrach <bachrach@ICSI.Berkeley.EDU>
    Date: Mon, 10 Feb 92 19:23:16 PST
    To: Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU
    Subject: CMUCL Native CLOS 
    
        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

    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.
    [...]  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.

That is what I was suggesting, though with the modification that builtin
class IDs would be known compile-time constants.  This allows tests for
these classes to become in effect a tag check.  This could probably be
extended to user-defined classes as well, given appropriate declarations.
    
    Personally, I'm not so concerned with a measely 32bit heap.

That is reasonable given current technology, but when doing a redesign like
this, you need to leave some room for future growth.

    Furthermore, I'm confident that accessing the upper 32bits of a 64bit
    word will be much faster than accessing the upper 20bits.

On a 64bit machine, with the value in a register, it should be one cycle
either way (a shift).  If the value is in memory, and you use all 32 bits,
then you could avoid the shift by using a 32bit load (which would save 1/3
to 1/2.)  But probably the in-memory scenario is not the most common.  You
are probably going to use the pointer part if you are looking at the tag,
so you might as well do a 64bit load.

It would be pointless to use less than the whole upper word for the tag on
a 32bit machine, since such machines can't address more than 32bits anyway.
    
    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.

Yes, I agree that subclass would be the natural semantics.  My intent was
to point out that if you did take those semantics, and if you did allow
subclassing numbers, then existing numeric type declarations would become
basically worthless.

I guess part of my confusion about subclassing builtins comes from the old
issue of inheritance as reuse of implementation v.s. reuse of interface.
The implementation of builtins is extremely implementation-dependent, so it
really doesn't make sense for a user to inherit FIXNUM to reuse the
bit-level implementation.  But FIXNUMs do have a perfectly well-defined
interface, and it would be plausible for users to create instances that
indicate they adhere to the FIXNUM protocol by inheriting FIXNUM.
    
    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.

Yes, it is a very general and powerful technique for optimizing dynamic
type systems.  The main drawbacks are the code bloat and/or requirement for
dynamic compilation.
    
    Are their any immediate plans for implementing the
    dynamic-extent declaration for declaring &rest args on the stack as
    well as other local variables?

Yes.  Though you may be thinking in particular of how to propagate argument
lists through functions, which I intend to approach in a different way.
&rest and &key args are already built on an internal "more arg" mechanism
which represents incoming args as a contiguous chunk of words on the stack
(no list CDR overhead.)  My idea is to add a primitive that allows a
function to be re-called with your function's incoming arguments.
    
    Are there any immediate plans to implement a multiprocessing facility
    that would allow multiple threads within one lisp process?

Fairly immediate.  It is William's next big project after debugging &
tuning the generational GC.  In the process of coding generational GC, many
of the low-level hooks for lightweight processes have already been added.
    
    Finally, are there any immediate plans to port CMUCL to the new $5000
    34-SPEC-Mark HP snake machine?

Yes.  Tim Moore at Utah is working on debugging a compiler backend that he
has already written.  Finishing time will depend on how much time Tim can
spend.  Note also that this will only run under Mach or OSF/1, and not
the old HP/UX.

  Rob