Kernel LISP - how low down can it go?

[BRIAN SPILSBURY]

DH> As an example, with C on a 386 I can use the full 32 bits of a register to
DH> store value information since everything is statically typed.  This lets
DH> me do interesting things with say virtual memory and exception handling
DH> (e.g. I can get the address of a faulting instruction).  If I now move to
DH> a dynamically typed language such as Scheme (I appologise now for my lack
DH> of knowledge of CL) I either need to create a new primitive type that can
DH> give me 32 bits still whilst still providing a type tag or I need to use
DH> some sort of language dialect that uses type inference (something like
DH> Infer say).

You need the type-information to be accessable to anything that asks for it,
but this does not necessarily need to be the actual object itself.

If I have a container that only contains 32 bit bitvectors then I don't
need to type each of the bitvectors inside themselves, the type is
necessarily avaiable in the container.

If I move one of those 32-bit bit-vectors into a slot of a structure
that is likewise specialzied onto a 32-bit bit-vector then I can
just copy it, since the type is in the container, and you can't
directly refer to it.

The main catch comes with type-indeterminate values. Where you can
exactly determine and specify the type you get code that's as happy
as C, and may not need tagging.

DH> Does anyone know of any tricks that allow me to hit the sort of C
DH> performance levels, or anywhere where I might be able to find such
DH> information?  Alternatively, if the answer is to resort to a core
DH> assembler runtime system, does anyone have any ideas on what it ought to
DH> contain? 

Imho the main thing is to think of static-typing as a subset of
dynamic, where the dynamic is pinned down enough we can do it static.
Then its just a matter of thinking carefully about how tightly things
need to be pinned down.

I would personally extend the lisp-system into covering all the assembly
level operations, and then avoid using them as much as possible.

With this we should be able to exceed C code performance in many areas.

Brian