Remember the Flux OS toolkit? [Re: Model]

[Dwight Hughes]

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
site.

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).

-- Dwight

| From: BRIAN SPILSBURY <zhivago@iglou.com>
| 
| > I hesitated to bring this up here.  I feel it will probably get shot
down
| > pretty thoroughly.  How about ANSI Forth (with much extension) as the
low
| > level core (and ultimately the implementation language for whatever
Lisp
| > 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
that
| >     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
well.
| >     Reflection seems possible, but I don't know of any practice along
these
| >     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.
| 
| Brian
|