[LispM-Hackers] Re: E3 docs

[James A. Crippen]

Dan Moniz <dnm@pobox.com> writes:

> Hi James,
> 
> I'm all set up on kappa and poked around the /home/lispm directory
> for docs.  Before I go about recursively FTPing all the PDFs and
> what not, is there a massive tarball somewhere that I should grab
> instead? I have a lengthy train trip coming up and figured this
> might be a good time to get some reading in.

There's not one particular tarball that you could grab.  This is
probably because we're not all that organized yet.  But I can give you
a guide to what's useful.

BTW, I hope your trip is a week or two long if you want to finish all
these docs... :^)

The following files are essential documentation:

  kappa:/home/lispm/explorer-docs/e3-docs/SSDN2.{ps|pdf}.gz

The System Software Design Notes, 2nd Rev.  This explains the low
level details of the Explorer system.  It's not a coherent book, but a
collection of documents on various topics.

  kappa:/home/lispm/explorer-docs/documents/E2-proc-gen.pdf

The Explorer II Processor General Description.  Just what it says.
Not detailed enough for my liking, but it's what we've got.  There are
some odd-sized pages in this document, so beware if printing.

  CVS:e3/docs/ti-lispref/lispref-chapter-*.txt

From the CVS repository.  These are selected chapters from the
Explorer Lisp Reference manual, relevant to the lower levels of the
system.

  CVS:e3/docs/funcall-notes.txt

Notes I have extracted from the above resources and from list
discussions on function calling, which is our current major task (ie,
implementing the function calling macroinsns CALL-*).

  kappa:/home/lispm/00TARBALLS/explorer-lispm-sources.tar.gz

This is the tarball of sources to the Explorer System, the OS that ran
on Explorers.  It never had an official name, unlike Symbolics's
Genera.  I think its last name was 'Release 6' or the like.  There are
a couple of files in it that you should take with for reading:

  explorer-lispm-sources/ucode/*.lisp

Particularly lroy-qcom.lisp but the others are important as well.

You'll also want a copy of the current E3 sources, I recommend
checking them out and pretty printing them from Emacs, then sticking
them in a 3-ring binder.  The sources aren't exactly beautiful, and
they're a little hard to follow at times.  Just keep in mind the stuff
we're emulating and it'll make more sense.

With that huge pile of dead trees you should be plenty busy for a long
time.  If you have a laptop I'd recommend leaving most everything in
electronic form and reading them online.  The only thing I would print
out for long term use (other than selected Lispm source files) would
be the SSDN2.  This is a hefty document (it's all scanned pages) so
you should probably take it to a local print shop and have them print
it double sided, then bind it in separate sections (I cut it in two,
the second book starting with chapter 12(?), "Closures").  In two or
more sections you can get it spiral bound which is easier to use than
comb binding.

Advice-wise, there's not much I can say.  The Explorer processor was a
64-bit microcode processor that loaded firmware written in the
microcode instruction format.  This microcode executed a macrocode
processor which ran Lisp-specific 16-bit macroinstructions that
operated on tagged 25-bit data (32-bit words with 2-bit cdr-code and
5-bit type tag).  Its method of booting is particular to Lisp
machines, which you may be familiar with from Symbolics experience.
The system boots (doing magic stuff with hardware and microcode), then
loads a 'load band' which is a dumped memory image from a running
system.  This image contains all the compiled code and data that makes
up the running system.

Our aim with E3 is to emulate the macrocode processor, which
conveniently fits both instructions and data on our 32-bit machines.
We lack the microcode sources, so we are having to write the macroop
set based entirely on extant documentation and what we can glean from
the load bands.  The emulator boots and loads the load band (N928.LOAD
is the generic load band from TI), doing byte swapping if necessary.
Once loaded it sets up the machine and tries to run the first
instruction.  That first instruction is a function CALL instruction,
which we're working on implementing right now.

'james

-- 
James A. Crippen <james@unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.