newLISP on a chip - is it possible?

[hilti]

Hi!



I just ran across this project: python on a chip

http://code.google.com/p/python-on-a-chip/downloads/list">//http://code.google.com/p/python-on-a-chip/downloads/list



Very interesting. Just imagine how cool it would be to run newLISP on Arduino or mBed (http://mbed.org/">//http://mbed.org/)



Cheers

Hilti

[kanen]

I find this topic fascinating.



When we were doing kozoru, we basically did the same thing, but with iron. We had custom OpenBSD kernels, on flash drives, that would boot directly into newLISP with no operating system at all, other than the newLISP interpreter.



It went from the Unix kernel to newLISP directly. If you exited newLISP, the system rebooted (fast) and back into newLISP. It was great.



A chip would be better, though.

[kanen]

Not quite "on a chip" -- but, fundamentally the same thing.



Movitz is a small (almost) ANSI complete Common Lisp which runs on bare x86



http://common-lisp.net/project/movitz/">http://common-lisp.net/project/movitz/

http://en.wikipedia.org/wiki/Movitz">http://en.wikipedia.org/wiki/Movitz

http://kmkeen.com/tiny-code/index.html">http://kmkeen.com/tiny-code/index.html



Seems like we could do this with newLISP as well. There's a good kernel-level programming document available here: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.96.4404&rep=rep1&type=pdf">http://citeseerx.ist.psu.edu/viewdoc/do ... 1&type=pdf">http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.96.4404&rep=rep1&type=pdf

[vsedach]

x86 or ARM is one thing, PIC and Atmel are another.



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:



http://www.ift.ulaval.ca/~dadub100/files/ll3.pdf">http://www.ift.ulaval.ca/~dadub100/files/ll3.pdf

http://www.ift.ulaval.ca/~dadub100/files/picbit.pdf">http://www.ift.ulaval.ca/~dadub100/files/picbit.pdf

http://www.ift.ulaval.ca/~dadub100/files/HOSC.pdf">http://www.ift.ulaval.ca/~dadub100/files/HOSC.pdf



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:



http://www.scribd.com/doc/48181919/L-A-Common-Lisp-for-Embedded-Systems">http://www.scribd.com/doc/48181919/L-A- ... ed-Systems">http://www.scribd.com/doc/48181919/L-A-Common-Lisp-for-Embedded-Systems



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 http://cluecc.sourceforge.net/">http://cluecc.sourceforge.net/).



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 (http://mumble.net/~jar/tproject/">http://mumble.net/~jar/tproject/) was written. This is similar to the idea of "SysLisp" in Portable Standard Lisp - use a small subset core language to bootstrap the rest of the implementation.



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.