Re: SUN vs Lisp machine hardware differences?

[James Larus <larus%paris.Berkeley.EDU@ucbvax.berkeley.edu>]

         Date: Wed, 05 Aug 87 10:52:42 PDT
         From: larus%paris.Berkeley.EDU at berkeley.edu (James Larus)

         One other point that should not be lost in the discussion is that the
         Symbolics address space contains a lot more code and data than an
         equivalent Lisp address space on a Sun.  The Unix system code is
         written in C, which has a smaller object size than the current Sun
         Lisp code.  Also, a number of utilities that are part of the Lisp
         Machine address space (editors, mail programs, etc.) are dynamically
         loaded (i.e., processes), so to be fair, we must count part of the
         Unix file system as being in the "address space."

     Do you consider this a bug or a feature?  I consider it a great
     feature that I get to alter my editor, mail reader, network code,
     whatever, in lisp, rather than in some other language, and an even
     greater feature that they can each call parts of each other when
     necessary.

I consider it a feature.  I am not a fan of reinventing the wheel.
Unix's great strength is that a large number of disparate tools can be
used together--even from Lisp!  I can only sympathize with a small
company like Symbolics, which is forced to write and maintain an
entire system and to write code to track many different "standards"
such as TCP, Decnet, SNA, NFS, X, ....  The Lisp vendors on "stock
hardware" have a significant advantage in that they only need to
provide interfaces to other people's code.

I am not arguing that Unix's text streams are the solution to every
problem.  However, they work for in amazing number of situations,
witness GNU Emacs.  In more complex situations, a remote procedure
call mechanism would be a big help.

The other argument against this approach is that it is difficult to
write portable code.  The extreme consequences of this can be seen in
Smalltalk, which does not have a language definition: where does the
application stop and the system begin?  Of course, on the Symbolics,
you can stick to CLtL, but that would defeat your argument.

On the other hand, I understand the attractiveness of having a single
language environment with quick access to every routine every written.
I believe that the engineering and practical arguments are, however,
against this approach.


I should also take an opportunity to clarify my remark above in
light of Weinreb's reply to it that accused me of confusing virtual
and physical address space.  The two concepts are different, but not
separate. I see two advantages of the process model in this respect:

1.  When a process terminates, the OS can reclaim both address spaces.
In a single address space, the best you can hope to do is to page out
the task's pages.  However, these pages are likely to contain other
tasks' code and data (internal fragmentation) that reduce the
effectiveness of paging.

This means that statements like "you will never run a real Lisp on a
Sun because you don't have 2^X byte address spaces" are meaningless.
You don't need 2^(X-1) bytes of address spaces for the system code.

2.  Each process is a separate address space can be managed with
different policies as to their working set and paging algorithms.  I
can't see how to do this directly in a single address space except to
put the burden on the program (you know the arguments against that
one).


     I find it ironic that as Lucid is moving in this direction (e.g.
     editor in Lisp, multiple processes in one Lisp, etc) Sun went to
     Franz.

I would be very surprised to find that people at Sun who made this
decision are aware of this controversy and sided with my point of
view.

Franz also has multiple processes and interfaces to various window
systems.  Their approach (described in John Foderaro's column in the
most recent "Lisp Pointers") differs in the amount that they relie on
the Unix environment.

/Jim