[movitz-devel] Lisp compilation principles and SBCL internals

Semion Prihodko semion.ababo at gmail.com
Wed Aug 18 12:50:42 UTC 2010


Hi guys,

I'm a developer who likes to learn more about SBCL runtime internals.
Being on very early stages of new OS development I need to understand is
it worthy to build OS on top of lispy runtime. I see lisp-like language
as a main system language (like C language in Unix-like systems), so I
need to know if replacing ordinal stack / register virtual machine (I
prefer a managed environment) by a lisp runtime virtual machine will
make programs run more efficient?


I will describe my view. Let's imagine lisp runtime operating with
machine size numbers (arbitrary size numbers are on a layer above),
explicitly supporting arrays, different VOPs, etc. On the layer above
there is a main lispy language compiler. The question is the following:
will the lisp runtime playing the part of a virtual machine be worth to
base on (supposing that main language compiler will be able to pass
intermediate code to it more preserving original semantics for
optimization purposes compared to ordinal stack / register virtual
machine)?


My substantial lack of knowledge about modern lisp compilation forces me
to ask another, maybe stupid question. Is the lisp compilers at general
embed a minimal interpreter to compiled code? I mean, when I define a
function with some work flow (conditions, recursion, etc) is it
interpreted on the low level (of course, with some VOP blocks of machine
code inlined and some optimization transformations applied)? Under
interpretation I understand the process that flow in lisp processors
(chips), well described in the following white paper: “Design of
LISP-Based Processors or, SCHEME: A Dielectric LISP or, Finit Memories
Considered Harmful or, LAMBDA: Ultimate Opcode” by Guy Lewis Steele Jr.
and Gerald Jay Sussman.

Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/movitz-devel/attachments/20100818/9bc1c66a/attachment.html>


More information about the movitz-devel mailing list