Hi Henry,

Welcome. That is an interesting idea.

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

http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf

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

http://www.sonoma.edu/users/l/luvisi/sl5.c

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"

https://code.call-cc.org

Good luck and let us know how you get on!

Thanks,
Carl

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