Does anybody know, what happened to the e3 project? It was to become
an emulator for the TI explorer lisp machine and was apparently hosted
at www.unlambda.com. But since about a week, the site seems to be
dead.
Does anybody here know anything about it?
Thanks
Andreas
--
Wherever I lay my .emacs, there�s my $HOME.
From: Michael J. Ferrador
Subject: Symbolics Emulator at the end of Alpha
Date:
Message-ID: <3C601435.47B9002B@orn.com>
I was finding the 48/36 bit LispM emulation
on a 64 bit arch (Alpha), interesting
http://www2.thecia.net/users/ptw/VLM.html
w/ discussions of how suitable various modern RISC/VLIW might be
http://groups.google.com/groups?group=comp.lang.lisp
search on VLIW, Transmeta, Itanic, etc...
I'm sure there will support for Alpha, until even the server,
then consumer x86's catch-up and surpass http://www.microway.com/
But it is interesting to speculate, if Symbolics does more
than just another port, to another 64 bit architecture...
If enough Integer units were available for parallel execution,
Or enough micro-ops in a VLIW, or a wide enough FPGA, etc...
I was thinking of what else could be done in
"one" Lisp instruction with the 16/28 bits left over -
Low end machines w/o ECC - 6 bits for hamming code
additional tagging 2^n most used data types
Squeak Smalltalk does this
save-lisp could have an optional parameter to specify
which types / classes, to tune for a particular app core
trace/profile the init-function through for the types
"Michael J. Ferrador" <·····@orn.com> wrote in message news:<·················@orn.com>...
> I was finding the 48/36 bit LispM emulation
> on a 64 bit arch (Alpha), interesting
> http://www2.thecia.net/users/ptw/VLM.html
<snip>
> But it is interesting to speculate, if Symbolics does more
> than just another port, to another 64 bit architecture...
>
> If enough Integer units were available for parallel execution,
> Or enough micro-ops in a VLIW, or a wide enough FPGA, etc...
Did you read the posts here on this subject around 1997-8? The major perform-
ance challenge is to be able to emulate exceptions without the cost of a con-
text switch. On a lispm the microcode tests the compatibility and validity of
the type tags (or other tags like the cdr-code) for the operands of every ins-
truction and dispatches to different micro-routines that handle cleanup for the
cases which aren't just an ALU operation. They also dispatch on conditions like
integer overflow, to restart the operation as bignum arithmetic, and for the
really messy or invalid cases trap back out to 'macro-code' error handlers. This
all happens without the code to handle these cases cluttering the main macro-
instruction stream, so you have a 'generic instruction set'.
On a common superscalar architecture, the different pipelines execute indepen-
dent blocks of instructions, so I don't think this can be used to speed up the
checks that a lispm would do in microcode unless you do major instruction reor-
dering. Also remember that whenever one pipeline requires a result that another
is still in the process of computing, it stalls. Since most modern superscalar
processors have speculative execution, the 'fast path' or common case can spec-
ulatively execute while the tag tests are done in another pipeline - but this
is probably what happens already when such a processor runs code from any lisp
compiler.
On a VLIW machine the code for the different pipelines is more closely coupled,
so in theory the compiler has greater control over how the tag tests can be run
in parallel with the other stuff. But remember the issue is still how fast can a
tag mismatch be addressed - if you embed the code to deal with the different
cases right next to the common case you can run all of them without branching
and retrieve the result with predication. But this seems like a lot of code
bloat, and you might have been able to put something that did more useful work
in those slots.
Of all of these an FPGA seems like the most hopeful for really implementing the
performance characteristics of a lispm. For one thing you have a chance to make
a data path that carries tags in parallel and then splits them off for most ef-
ficient handling. Also remember that the real lispms during most of their exist-
ence were themselves implemented using programmable, generic logic parts. So if
the density of these devices has increased, what, a thousandfold? in the last 15
years, it should be doable in a single part today.
> I was thinking of what else could be done in
> "one" Lisp instruction with the 16/28 bits left over -
This is a really interesting question; what to do with the extra bits!
If you read comp.arch you will sooner or later come across the bonmot, "64 bits
may be too many, but 32 are too few." (the original author is lost in history, I
think)
>
> Low end machines w/o ECC - 6 bits for hamming code
I think software emulation of ECC is going to be pretty pointless.
>
> additional tagging 2^n most used data types
> Squeak Smalltalk does this
Where would you use this? Flavor dispatch? Accelerated default method combina-
tion for CLOS? In the lispm the tags are (almost entirely) for types of objects
that don't change from one to another. (cdr-codes are one big exception, there
might be some others). But CLOS objects can change to other types of CLOS object
so some thought needs to be put into stuffing data about the class into the
pointer word. There might be a way to put these extra bits into the header word
of the object without causing major problems, but (I don't know) this word may
already point to the object's class.
> save-lisp could have an optional parameter to specify
> which types / classes, to tune for a particular app core
> trace/profile the init-function through for the types
Another idea is that in specialized arrays all 64 bits could be used to hold
data, in the content part of the array.
regards, (and thank you for bringing this up =)
nate holloway
On Tue, 5 Feb 2002, Michael J. Ferrador wrote:
[snip]
> I was thinking of what else could be done in
> "one" Lisp instruction with the 16/28 bits left over -
>
> Low end machines w/o ECC - 6 bits for hamming code
>
> additional tagging 2^n most used data types
> Squeak Smalltalk does this
[snip]
If I'm following you, then no, it doesn't, at least in its current
implementation. There is a VM/Image (old) which has such support, mostly
with immediate characters and points.
There's a discussion currently on about whether to add this all more
generally.
(It, of course, has immediate SmallIntegers, a.k.a. FIXNUMs (I think).)
VisualWorks Smaltalk *may* have more. It has immediate characters, at
least:
http://wiki.cs.uiuc.edu/VisualWorks/Immediate+Selectors
Cheers,
Bijan Parsia.