Kernel LISP - how low down can it go?
Wed, 21 May 1997 22:59:01 +0200 (MET DST)
>: Dave Hudson
Hi Dave! Moving past VSTa?
> how low-level [is it] possible to get with something like Lisp
> before it's necessary to hit some sort of assembler code?
Well, there's been assembly in Lisp.
Lisp->native-code compilers can manipulate assembly, too,
so that you can definitively do whatever you want with Lisp.
For instance, you could have something like GCC's asm() statements,
where you specify a both the assembly code and its calling convention.
Of course, we could have several levels of hardware abstraction between
top-level lisp and binary code. Obviously, you can't arbitrarily mix code
between these levels; you need put low-level code into special sections.
The implementation of vectors as arrays in a flat Cish address space
would have somewhere something like:
(%%low-level-lambda (v n)
(%%peek (%%fixnum:+ v n))))
Note that this doesn't differ from what a C program would do,
only we have a fine-grained control on what stays implicit or not,
instead of having just some fixed levels of abstraction.
Anything you can do with a C syntax,
you can do it isomorphically with a SEXP syntax for the same ADT,
with *the same performance constraints*.
SEXPs are only a syntax that's practical for reflective purpose.
If you think it doesn't suit low-level sections,
use a Guile-style reader for inputing those sections.
In the end, the program will be ready to be processed by
the system's compiler/assembler in the same way.
That said, if what you want is write code that locally breaks high-level
invariants (calling conventions, typing, linearity/immutability/whatever,
register/memory usage and encoding, etc), you need:
(1) a block primitive that grants you atomicity wrt GC/interrupts/whatever,
and allows to specify the interfaces between the low-level code and
the high-level code;
(2) low-level primitives that break those invariants
(like using tagged 32-bit values as untyped integers)
With such a framework, you definitely *can* implement such things as
I/O, paging, GC, type encoding, persistence, bignums, complex numbers, etc.
Again, with LISP, we needn't and shouldn't focus on the syntax,
but on the semantics. And reflection allows you to express
a much wider range of semantics than C people can ever imagine.
== Fare' -- firstname.lastname@example.org -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
TUNES is a Useful, Not Expedient System