Re: SUN vs Lisp machine hardware differences?

[Scott Garren <garren@scrc-stony-brook.arpa>]

    Date: Wed, 29 Jul 87 17:32:56 PDT
    From: larus%paris.Berkeley.EDU@berkeley.edu (James Larus)

	 I would think the most serious one is address space.  Here's why we have
	 think we have to use lisp machines from Symbolics.  Perhaps some sun
	 users can enlighten me on how they (the Sun machines, not the users) compa
	re:

	 First, RAM:

	  CYC, the system I'm working on, needs at least 4 mw to even run, and 6
	  to be moderately comfortable.  I was dissapointed that under 7.1 I
	  couldn't bring a machine up to even 8 mw (high memory above 7.5 was
	  ignored.)  I think this limitation is going to become a real problem
	  for us in the next year or so.

    1 Symbolics MW ~ 4 MB since both Sun Common Lisps use 32 tagged pointers.

Only in the most general way.  Our users tell us that Lisp programs and
data are often up to four times as large on a Sun.  The Sun instruction
set does not map into Lisp well which results in much bigger programs.
For instance here is a trivial function that was disassembled on Sun
Lisp V2 and Symbolics:


(defun gp (a b) (+ a b))

On Symbolics (2 words - 8 bytes):
  0  ENTRY: 2 REQUIRED, 0 OPTIONAL
  1  PUSH-LOCAL FP|0            ;A
  2  BUILTIN +-INTERNAL STACK FP|1      ;B
  3  RETURN-STACK 


On the Sun (exact size? - large!):
        CMPI.W    #2, D6
        BEQ        L1
        MOVEA.L    (227,A4), A2
        JSR        (5,A2)
L1:     MOVEA.L    (-12,A6), A0
        MOVEA.L    (-16,A6), A1
        MOVE.L     A0, D4
        MOVE.L     A1, D5
        MOVE.W     D4, D7
        OR.W       D5, D7
        ANDI       #x3, D7
        BNE        L2
        ADD.L      D5, D4
        BVS        L3
L4:     MOVE.L     D4, (4,A6)
        MOVEA.L    (-4,A6), A5
        LEA        (-8,A6), A7
        MOVEA.L    (A7), A3
        JMP        (A3)
L3:     SUBX.L     D5, D4
L2:     MOVEA.L    (167,A4), A2
        JSR        (5,A2)
        BRA        L4

Lack on CDR-coding, boxing of numbers, and similar issues makes Lisp
data  structures much larger on traditional systems also.

It is also worth noting that traditional g.c.'s need huge amounts of
free virtual address space to be able to run at all but the ephemeral
g.c. will continue collecting until the very last bit of address space
is full of data which potentially makes the usable address twice as
large.  Combine this with the differences in the size of data and code
and our users find that the Symbolics 3600 architecture is much more
cost effective.