Are we dead or alive? (was Re: a good volunteer)

[John Morrison]

Hi All,

Please find below a perhaps slightly off-topic (in letter if not in
spirit) progress report.  I apologize in advance if the mention of the
J-word ("Java" -- shhhh) in this forum incites invective.  

I miss my old Symbolics terribly, and can't drive through Kendall Square
without looking at the Building Of Death (which housed both Symbolics
and OSF, both of which are not at all well companies) and fondly
remembering days filled with parentheses.  This has motivated me to try
and help out the freeware Java OS effort (www.jos.org) in the hope that
I will have an ersatz, commodity-priced (pc-compatible hardware) LispM
capability either in Java, or (preferably) in Scheme/Lisp.

I expect that by the end of this weekend, I will have released something
to help jumpstart the stalled JOS effort.  I have assembled a (mostly
C++ with a smattering of assembly) free cross-development toolchain and
used it to successfully build and download a native-code runtime which
does the obvious things (e.g., puts the [expletive deleted] Intel part
in flat 32-bit protected mode, probes memory, catches interrupts, etc.),
can also find command-line arguments in memory, and can read bytes from
named files stored in a sizeable uncompressed-zipfile ramdisk.  There is
also a self-hosted "emulation" build target so most
non-hardware-specific things can actually be debugged with a
source-level debugger.  The over-arching design goal is to do as little
in native code as is possible (which will, of course, entail writing
machine-specific bytecode, etc.).

The next Java-related step is to integrate a C++ JVM already under
development by another co-conspirator, and point it at the ramdisk
(which, obviously, would contain both machine-independent java/* classes
and machine-dependent classes for finishing intialization of the
hardware).  My co-conspirator actually wants to do the integration.

However, given what I really want is a LispM, I figure I've got two
options:

(1) The "Stay Focused" Option: keep slogging away now, and, sometime
much later, just use Kawa (or the equivalent then-available Scheme/Lisp
to bytecode compiler).

(2) The "Get Distracted" Option: rather than linking in a Java VM and
downloading a bytecode ramdisk, link in a Lisp/36xx/CADR VM (or
interpreter? SIOD?) and download Lisp code/bytecodes/bands/worlds
(whatever).

Perhaps somebody out there is interested in helping?  Most of the really
unpleasant grotty bits have been beaten into submission (there were two:
assembling the toolchain, and convincing the Pentium it wasn't an 8086
anymore -- sheesh -- so it should use a flat 32-bit non-segmented
address space in protected mode).

Now that I have assembled a UNIX-based "emulation" so one can work under
UNIX, and the kinks have (mostly) been wrung out of the toolchain so
that cross-development is pretty quick (about 30 seconds), it's really
not that unpleasant to work on!

-jm

-- 
==== John Morrison ==== jm@mak.com == http://www.mak.com/welcome.html
==== MaK Technologies Inc., 185 Alewife Brook Parkway, Cambridge, MA
02138
==== vox:617-876-8085 x115
==== fax:617-876-9208