Dube and Feeley came up with a very compact VM for R4RS Scheme that can run in < 5 KiB RAM and < 15 KiB ROM on PIC controllers:
Since newLisp doesn't need a GC, the runtime requirements should be much smaller than for Scheme.
Brooks and Rosenberg came up with a cross-compiler from CL to bare-bones m68k for robots:
That's fundamentally the same idea as Movitz.
IMO the Movitz approach is problematic - building a new cross-compiler for every architecture is no fun, and it completely punts on the hard problems of the runtime (memory allocation, threads/processes, I/O, etc.) and more importantly on how to make the runtime portable.
I like the OpenBSD approach kanen described - get a kernel, libc and newLisp together, and you have an embedded newLisp system that can run on an ARM controller right now.
The problem with that is if you want to make it smaller, I don't think you can move newLisp into the kernel since there's probably all kinds of stupid restrictions and hard-coded limitations on allocation and stack sizes there (at least that's the case with the Linux kernel).
I'm trying to build a Common Lisp operating system by taking the drivers from OpenBSD and putting them through a C to Common Lisp compiler (I was originally going to write my own by taking pieces from Zeta-C, but now I'm hoping to use
OpenBSD has a very good I/O abstraction layer that separates the drivers from machine internals, and OpenBSD only comes with Free Software drivers, which makes it a really great kernel IMO (that, and the source quality - Linux is terrible in comparison).
The other part is going to come through writing the runtime in a restricted dialect of Common Lisp. This is for example how the garbage collector for the T Scheme compiler (
By contrast, Movitz uses a non-boostrappable (needs a full other Common Lisp implementation) cross-compiler, and I think all Lisp implementations today (newLisp certainly, but also including native-code compilers like SBCL and Clozure) have a C runtime that provides allocation, garbage collection, and I/O.
I'm hoping to reuse SBCL and implement a new backend (for each instruction set, in parallel with the "regular" backends) with the restricted "system" subset for writing the runtime to run natively on the processor. Then build the OpenBSD I/O abstraction layer, and hopefully get the OpenBSD drivers compiled to Common Lisp and running without any modifications.
I guess the lesson here is that there's lots of ways to get newLisp to run on hardware, but unless you don't mind bringing along the "C virtual machine" (OS + libc), you're going to have to do a little work.