e3 and unlambda 
Author Message
 e3 and unlambda

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, theres my $HOME.



Thu, 15 Jul 2004 17:03:24 GMT  
 e3 and unlambda
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



Sun, 25 Jul 2004 01:19:50 GMT  
 e3 and unlambda

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

Quote:
> 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)

Quote:

>  Low end machines w/o ECC - 6 bits for hamming code

I think software emulation of ECC is going to be pretty pointless.

Quote:

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

Quote:
>      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



Mon, 26 Jul 2004 19:03:36 GMT  
 e3 and unlambda

[snip]

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



Tue, 27 Jul 2004 08:38:04 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Hooking Int21/E3 (NetWare) -- samples or tips?

2. Platinum FastUnload E3 user exit in COBOL II

3. enum _zut { e1, e2, e3 } with ACL

4. I heart Unlambda

5. unlambda interpreter

6. The Unlambda programming language

7. unlambda.py

8. ANN: unlambda.py

9. PDH MUX (E2,E3) and frame (E1,T1,E2 ...) based device VHDL examples

 

 
Powered by phpBB® Forum Software