Remember the Flux OS toolkit? [Re: Model]
Sat, 10 May 1997 18:46:16 -0500
Where did this business with Forth come from? Apparently some of you
came in late to the picture show, so you need to go to
<http://www.cs.utah.edu/projects/flux/oskit/> and check out the
Flux OS toolkit -- it has everything needed to kickstart the
project - even adapting CMU-CL to run on top of it and fully
compile shouldn't be a huge problem. It contains full bootstap
code, MMU code, management of the x86 architecture, PCI bus
support, low-level debugging functions, wrappers for drivers from
NetBSD, FreeBSD, Linux ... and its FREE. The only holdup is they
are releasing a new version of it -- should only be a couple of
weeks (they've had previous versions so one more shouldn't stress
them out too much). Preliminary documentation is available from this
I think CMU-CL could be adapted or specialized to create the mini-lisp
you are desiring and it already has very good native code generation
(and not just for the x86 architecture).
| From: BRIAN SPILSBURY <firstname.lastname@example.org>
| > I hesitated to bring this up here. I feel it will probably get shot
| > pretty thoroughly. How about ANSI Forth (with much extension) as the
| > level core (and ultimately the implementation language for whatever
| > is chosen, until the Lisp compiles itself and we can throw away that
| > compiler).
| I'm not familiar with forth, but from what I've heard it is a
| good choice for extremely low level code, and from memory it probably
| has the reflective properties we need, without lots of overhead.
| > Advantages:
| > - Many of today's machines (Sparcs, PowerPCs, some PCI-bus machines)
| > come with a full ANSI Forth core in the OpenBoot Firmware. There
| > will be for these machines complete low level diagnostics and some
| > primitive kind of device driver available for all supported
| > devices. Those machines without OpenBoot Firmware could be made
| > to quickly load an ANSI Forth core.
| This is an excellent point. :) Device drivers are a bastard to write.
| > - Forth is well known to port very easily and runs in all kinds of
| > environments. If the LispVM were implemented in Forth then we
| > could quickly bring it up under various OS's, standalone, have
| > real-time subset implementations for embedded distributed
| > applications, etc. etc. A portable Forth like GForth (GNU)
| > could be used for initial ports. One report I read recently was
| > 2 guys brought up GForth in a new embedded environment on a
| > new machine architecture in a weekend. Now, they feel with the
| > work they did to simplify the porting, it could be done in an
| > >afternoon<.
| > - Mop systems have been implemented in Forth and seem to work quite
| > Reflection seems possible, but I don't know of any practice along
| > lines.
| This could be the only real sticking point.
| > Disadvantages:
| > - Including threading support might be tricky in any portable way.
| I can't think of any portable threading systems, but it should be
| relatively easy, this is where people want to think if they want
| a continuation passing style system, or one with chunky stacks.
| > - Forth scales poorly, but I do propose getting to a Lisp language
| > fairly quickly.
| Yeah, it would be interesting to see a toy lisp-over-forth system.
| There may be one already around, I'll have a look over the web.
| but I think its a great idea, and if you haven't hit the nail on the head
| you're not far off.