Position & proposal

[William A. Barnett-Lewis]

Time to stick my neck out to the chopping block. All constructive
criticism will be gratefully accepted.

William


 Y.A.L.M.
(AKA LispOS)
Position & proposal
William Barnett-Lewis
wlewis@mailbag.com

Introduction:

A bit over 20 years ago, the MIT AI Lab created a Personal Computer and
programming system that
was significantly ahead of it's time. If one rereads today the early
research and technical
papers of this project, one can sometimes get the impression that they
were written in the last
year.  However, not everything in these systems has perfectly withstood
the test of time. This
project's goal is not to simply recreate the CONS or CADR machines, but
to use them as the
starting point and inspiration much as Bell Labs Unix Version 7, via
Andrew Tannenbaum's MINIX,
was Linus Torvald's inspiration for his LINUX kernel.

The basic assumptions behind creating Yet Another Lisp Machine are
two-fold: 
1)  that a networkable _personal_ computer provides greater productivity
than any form of timesharing -
whether it's called a Network Computer, Java, or mainframe and 
2)  that Lisp is arguably superior (or at least more fun) as a systems
programming language.

As an operating system, it has to support both day to day productive
work, while still enabling
research in programming language and operating system issues.

Implementation:

The initial version of a LispOS is best done by simple conversion of
CMUCL into a standalone
system with the aid of the FLUX toolkit from the University of Utah.
This version is simply for
use as a bootstrap to allow work to begin on a complete Hardware
Abstraction Layer for a generic
PC platform.

The minimum reference platform for the HAL should be: 
i486DX at 50 MHz. 
16 MB RAM 
IDE hard disk with at least 100 MB free space 
2 MB VESA compatible SVGA frame buffer and monitor 
standard 101 keyboard and 2 button (sigh...) mouse 
ATAPI CD-ROM and tape 
Sound Blaster compatible audio 
modem
Ethernet

Anything beyond this short list would be added as necessary, but would
not be a high initial
priority. The emphasis is on supporting only the most common and
inexpensive PC hardware, not
everything under the sun. For example, SCSI support would give far
greater performance than
ATAPI/IDE, however at the cost of a far wider amount of hardware of
varying complexity to
support at differing levels of conformance. Do we support SCSI- I, II,
or III? Initially, none
of them.

Once a baseline system is up and running, then extensions to the system
can be made to weed out
the non-Lisp support code. This will be made easier if there are
available source distributions
from any of the prior LispM systems. This would allow the implementers
to study not only how
such code can be written, but also to see what was done a) right & b)
wrong the last time
around.

	I/O: all standard PC/AT ports will be supported. Items such as the
Universal Serial Bus can wait
until there is actually a significant amount of hardware shipping that
uses it. Busses supported
will be PCI and ISA. Hard interrupts will be used to service these. 
	Data representation: initially as in CMUCL, but should move to a 2 word
representation using 
IEEE floating point NAN instructions as the tags. 
	POS: Some form of persistent object store similar in functionality to
the University of 
Wisconsin-Madison's SHORE project is necessary to replace traditional
byte-stream file systems. 
However, as a practical issue, files system support is still necessary
underneath both the POS and LispOS. 
Initially the file systems that will be needed to be supported are VFAT,
EXT2FS, and ISO CD-ROM FS. 
	CG/VM: Paging VM with Baker's Treadmill GC should be implemented. 
	Other: Threads and SMP support will be needed eventually. I do not
consider either to be of 
high priority.

Language Implementation:

The main language will be ANSI standard Common Lisp/CLOS. The advantages
of using an imperfect
standardized language far outweigh the advantages of a perfect
non-standard language. This
should allow us to incorporate much already freely available code into
the system. As in any
proper Lisp implementation, the language will be defined in itself with
the source code
available. This should allow for extensions to the basic system to be
created as desired.
Someone may wish to implement Baker's concept of immutability or a
Zeta-Lisp personality for the
system. However, for purely pragmatic reasons, the primary
implementation should be strict ANSI
compliant.

Beyond this, however, there are several additional modules that are
necessary in a stand alone
system that are not in the standard. These include, but are probably not
limited to: 
	Display: EW based using only VESA standard SVGA modes. This provides a
BIOS level to 
program to on the video hardware This will provide some insulation from
the downright nasty-ness 
of most modern video cards. 
	Compiler: Python seems to be the best available and is one the single
biggest reasons to
use the CMUCL system as the basis of the initial system. 
	Editor: Both Emacs and Sedit clones should be provided. Perhaps both
textual and structural 
editing capabilities can be built into a single editor? 
	Networking: TCP/IP over Ethernet and PPP are vital to the usability of
the LispOS. 
	Device Drivers: Ultimately, we want to be able to write drivers for new
and/or previously 
unsupported hardware in Lisp. To do this will require the abstraction of
these out of traditional 
kernel space.