I am looking for information on the hardware and software architecture
of the Symbolics Lisp Machine; I have scoured around some on the net,
but to no avail, and a library search doesn't seem to have helped
either (probably due to a miserable selection of books on Lisp).
Also, I understand that the SPARC was originally designed with
efficient execution of Lisp code in mind. Does anyone have any
details, or perhaps know where I can find them (all I am fuzzily aware
of some hardware support for tags)?
If anyone can help with pointers to books, papers, or on-line
information, I would be very grateful. Emailed replies might be best;
that way I can summarise for the net.
Thanks,
<b
--
Bryan O'Sullivan email: ········@serd.cscs.ch
Swiss Scientific Computing Centre ········@tcd.ie
(also Trinity College, Dublin, Ireland) url: http://scrg.cs.tcd.ie/
In article <······················@vevey.serd.cscs.ch>,
········@serd.cscs.ch (Bryan O'Sullivan) wrote:
> I am looking for information on the hardware and software architecture
> of the Symbolics Lisp Machine; I have scoured around some on the net,
> but to no avail, and a library search doesn't seem to have helped
> either (probably due to a miserable selection of books on Lisp).
Try to get one of the old Symbolics manuals:
"Symbolics Technical Summary"
(mine is from October 85, ...will never give it away :-)
Maybe you can catch one by getting a second-hand 36xx-Lispm
(consider the selling off these days).
>
> Also, I understand that the SPARC was originally designed with
> efficient execution of Lisp code in mind. Does anyone have any
> details, or perhaps know where I can find them (all I am fuzzily aware
> of some hardware support for tags)?
>
See e.g. the article "Implementing Lisp on Standard Hardware"
from JonL White and S. Kaphan. ("Sun Technology, The Journal
for Sun-Users, Winter 1986, pp. 63-69).
Ralf Moeller
________________________________________
Ralf Moeller
University of Hamburg
Bodenstedtstr. 16
22765 Hamburg
Germany
Phone: ++40 4123 6134
Fax ++40 4123 6530
Email: ·······@informatik.uni-hamburg.de
········@serd.cscs.ch (Bryan O'Sullivan) writes:
>I am looking for information on the hardware and software architecture
>of the Symbolics Lisp Machine; I have scoured around some on the net,
>but to no avail, and a library search doesn't seem to have helped
>either (probably due to a miserable selection of books on Lisp).
Peter M. Kogge: "The Architecture of Symbolic Computers, McGraw-Hill
1991. ISBN 0-07-035596-7.
Excellent book!
>Also, I understand that the SPARC was originally designed with
>efficient execution of Lisp code in mind. Does anyone have any
>details, or perhaps know where I can find them (all I am fuzzily aware
>of some hardware support for tags)?
'Designed with Lisp code in mind'... Well, there are some features in
the SPARC processor that could potentially speed up Lisp code.
The first one are 'taggend arithmetic' instructions for addition and
subtraction of integers. Two of 32 bits of the operands are
interpreted as 'tag'. The one of these two bits is non-zero, a trap is
triggered or a special overflow bit is set. The SPARC Architecture
Manual suggest: "One possible model for targeting is to use a tag
value of 0 for integers, and a tag value of 3 for pointers to pairs of
words (that is, list cells). Using this model, suppose that p is a
tagged pointer to a list cell (that is, p has "3" in its low-order two
bits). Since load/store instructions execute successfully only with
properly aligned address, if p is a list cell with a tag of "3" (a
pointer), a load/store word instruction with an address specifier of
"p - 3" or "p + 1" will succeed, accessing the first or second word
(respectively) of the list cell. If p is not a pointer (that is,
contains a trap other that 3), such a load/store will cause a
mem_adress_not_aligned trap. This scheme can be used to test for
unexpected data types."
[excuse me for some bad english]
Well, I asked my compiler (Harlequin) and found out, that these tagged
operations are used rarely. Unoptimized code without declarations uses
them, but optimized code is almost free of them. If your need the
speed you will certainly declare your integers, so I think these
instructions make a difference only for programs that are
intentionally slow.
The second feature that could be considered to support Lisp are the
register windows. I consider them to be a bad thing since the cpu
speed is so much increased compared to memory speed. While register
windows might speed up programs that makes many function calls (Lisp
programs are certainly such programs), it will slow down the whole
systems if the register set will overflow (about 500 cycles are
wasted, as I heard in comp.arch).
Well, I'd like to hear some implementation wizards' comments on that.
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@wavehh.hanse.de>,Voice+4940-5221829,Fax.-5228536
Smile! >8=B >:)