Position & proposal

[Dwight Hughes]

| From: William A. Barnett-Lewis <wlewis@mailbag.com>
| 
|  Y.A.L.M.
| (AKA LispOS)
| Position & proposal
| William Barnett-Lewis
| wlewis@mailbag.com
| 
| Introduction:
| 
  [ good intro snipped ]
| 
| 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 

By _personal_ computer I take it that it should be designed to maximize
the productivity and power available to its specific user -- LispOS might
have other "personalities" but this should be the *primary* one and the
one we initially design for.

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

I would add here that the entire system should be explorable and should,
to the greatest extent practical, be implemented so its entirety is
directly available for study, modification, extension, customization from
within the LispOS environment.

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

There is also a middle ground that we could look at - that is to 
actually _build up_ the minimal level of the Flux toolkit with modules
for doing whatever is needed or desired (in C, to begin with). The 
code could be ripped out of various Linux or *BSD sources as desired.
This could give us most of the HAL layer without excessive pain or
adding a lot of complexity.

  [ good hardware reference system ]
| 
| 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.

What is the status of possibly getting the Symbolics docs online?

...
| 	Data representation: initially as in CMUCL, but should move to a 2 word
| representation using 
| IEEE floating point NAN instructions as the tags. 

Could you explain a bit about the advantages and the mechanism of this?

...
| 	CG/VM: Paging VM with Baker's Treadmill GC should be implemented.

There is more discussion needed on exactly what GC, but this is a good
place to start.

| 	Other: Threads and SMP support will be needed eventually. I do not
| consider either to be of 
| high priority.

Well, threads would certainly have a higher priority than SMP.

 [ standard language issues ]

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

What is EW? Please excuse my ignorance.

Using VESA standard SVGA modes at least gives us a standard definition to
code to.

| 	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? 

This is one area of CMUCL we need to look at carefully -- how much of the
Hemlock editor can we bring over to a non-X platform?

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

We should set LispOS up so we can use both encapsulated drivers (like
Flux) and "native" drivers at the same time, then one by one add critical
"native" drivers to LispOS. We could then have a certain very limited
number
of hardware configurations that were full native, all the rest being
mixed mode or entirely encapsulated.

-- Dwight