Kernel LISP - how low down can it go?

Wed, 21 May 1997 21:29:55 -0400 (EDT)

DwH> Well, the true Kernel Lisp would probably have to support explicit typing
DwH> and you would probably have to use it to get efficiency at the lowest
DwH> level. You could probably deal with tags for a compound object rather
DwH> efficiently - an object header word that tags a byte vector, 16 bit word
DwH> vector, 32 bit word vector, etc. and have efficient operations defined
DwH> for those within the Lisp compiler. At the cost of some memory you

Yeah, putting the type info into the container for a type-specialized
container seems to be the go, at least its what I'm playing with at the
moment. :)

DwH> I *really* don't like the idea of using assembly for the runtime. For
DwH> one, it is hell to write and to change -- the LispOS needs room to easily
DwH> evolve and change from bottom to top. For another, the assembly portions
DwH> will be as opaque as hardware to the higher level LispOS. We want to
DwH> be able to change and update and fix *everything* from within the LispOS.
DwH> To get there I think we will need to either define a new dialect of Lisp
DwH> or a specialized extended subset of CL to get down to the hardware
DwH> efficiently.

I've been thinking about this for a while, I think the best solution
may be to extend the lisp-set into covering the assembly-level operations.

(bnz #r0)

etc (while keeping this to a minimum)