Hi Henry,

Welcome. That is an interesting idea.

You may find something useful in the paper, "An Incremental Approach to
Compiler Construction", here:


Here is a very small implementation of Lisp by Andru Luvisi. It is an
interpreter in just 300 lines of C and quite readable:


There is an implementation of Scheme called Chicken that compiles to C
using Continuation Passing Style, which you may well be familiar with as it
uses the approach from your very own paper(!?), "Cheney on the MTA"


Good luck and let us know how you get on!


On 20 August 2016 at 09:33, Henry Baker <hbak...@pipeline.com> wrote:

> Hi all:
> I just discovered your project today, and was quite intrigued by what
> you've accomplished.
> I am particularly interested in "bare metal" implementations of Lisp &
> Lisp-like languages; part of my interest is analogous to the MirageOS
> "unikernal" concept; part of my interest is in gaining access to HW--e.g.,
> page tables for more efficient implementation of large arrays.
> I've worked on tiny languages before -- e.g., "Comfy" for the 8-bit
> Apple][/Attari 6502:
> http://home.pipeline.com/~hbaker1/sigplannotices/sigcol03.pdf
> http://home.pipeline.com/~hbaker1/sigplannotices/sigcol04.pdf
> My approach is to write a machine-language compiler in a subset of Common
> Lisp, and then simply port that subset to the bare metal.
> However, I don't want to do too much work, so I'd like to abstract away
> many of the machine language issues.
> I was hoping to come up with a machine of 3 sizes: 16-bit, 32-bit or
> 64-bit "words"; this would enable a "small", "medium" and "large" versions
> of this Lisp.
> The machine would have some number of "registers" of the standard word
> size, some of which (I hope) would map directly into machine registers.
> Most operations would operate on words, so as not to have to worry about
> byte ordering.
> The byte stuff would likely have to be done as an escape mechanism to
> incorporate raw bits into the instruction stream.
> I don't want to have to re-invent C, relocatable binaries, etc., so the
> idea is to completely dispense with assembler, C, loaders, etc., by
> compiling directly into memory (a la the original 1960's Lisps).
> So long as the compiler is *one-pass*, and doesn't do any complex
> optimizations, it can run at *line speed* -- i.e., it can compile at the
> same rate that it can read Lisp S-expressions from a file system.  Hence,
> there is very little advantage in ever storing compiled code in a file
> system.
> (Perhaps another way to look at this is as a 'just-in-time' compiler,
> where 'just-in-time' is when the code is loaded; since the compilation
> process could be functional, one could conceivably *page* these
> compilations in/out of memory a la Maclisp/Macsyma's load-on-demand
> functions.)
> The low-level portion of this Lisp would be *stackless*, and would look
> more like an Actor machine which is passed arguments + a "continuation"
> thunk/closure.
> A stackless machine would enable painless multiprocessing, whereby a
> context switch can occur at every function call.  Since iterations are just
> tail-recursions, context switches can occur very often and very quickly.
> An initial experiment is a tiny *functional* Lisp based on ref counts.
> This eliminates the need for a traditional GC, and can potentially provide
> better real-time response.
> BTW, here is the factorial function written in this functional Lisp:
> (defun fact1(f n)
>   (if (zerop n) 1
>     (* n (funcall f f (1- n)))))
> (defun factorial (n)
>   (funcall #'fact1 #'fact1 n))
> (Of course, to compile this into an Actorish execution model, you need to
> compile into continuation-passing form.)
> ---
> Since you all have been looking at tiny Lisps, do you have any
> recommendations of tiny Lisps to look at & play with?
> Thanks very much for any info & help.
> Henry Baker
> Santa Barbara, CA
> home.pipeline.com/~hbaker1
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to