From: wilson@cs.utexas.edu (Paul Wilson)
Newsgroups: comp.arch
Subject: Re: Ideas for new LISP Machines
Date: 9 Apr 1992 16:38:21 -0500
Organization: CS Dept, University of Texas at Austin
NNTP-Posting-Host: estoril.cs.utexas.edu
Keywords: LISP machines

In article <3472@disuns2.epfl.ch> baechler@liasun3.epfl.ch (Emmanuel Baechler) writes:
>In article <1992Apr1.033547.20514@athena.mit.edu>, pdp8@m4-035-4.MIT.EDU (John W.F. McClain) writes:
>|> What is the general feeling on purpose built LISP machines.  Ignoring
>|> marketing issues do they make sense from a technical viewpoint, or is
>|> it more effective to take a RS6000 or a DECstation and write a virtual
>|> LISP machine.
>
>Purpose buit LISP machines have the advantage that many of their important
>operations are directly supported by the hardware or the microcode. If memory
>serves me, this is for example the case for the Flavor Sytem on Symbolics.
>I read at several times that this support is very important for the speed
>of these operations.

It's very unclear (to me, anyway) that you can't fix this in software.
The aggressive compiler techniques that the Self group (at Stanford
and SunLabs, cited in an earlier post) have developed appear to alleviate
much of the dispatching cost of object-oriented systems.  By and large,
most concepually dynamic dispatches can be figured out by the compiler
to some degree or other.  You inline a lot of routines into their callers,
and then do what amounts to interprocedural type flow (and integer subrange)
analysis.  You also come up with special-purpose versions of methods
customized for particular classes of call sites (e.g., particular argument
types) and things like that.  Most type dispatches either go away entirely
or compile into something like a simple test for the usual case and a
procedure call.  I'd think this would be increasingly important on
heavily pipelined machines, where serious multiway dispatches cause
big branch prediction and pipeline bubble problems.

One important thing to remember is that the big benefit isn't just
in reducing the cost of dispatching per se, but in allowing optimization
across message sends---you eliminate lots of redundant checking and
other work that otherwise may get done (belt-and-suspenders style)
in both the caller and the callee (uh, er... sender and receiver).
Hardware support for dynamic dispatching only gets you the direct
benefit, not the indirect (optimization opportunity) benefit, which
appears to be greater.

>This discussion arose several times on the Symbolics Lisp Users Groups. At
>each time the "gurus" answered that a software simulation, although feasible,
>would result in a very slow machine. I don't know wether this situation has
>really changed with the new RISC machines. There was also a time where TI was
>developing a microprocessor with writable microcode. This can be a solution,
>if it ever succeeds.

I think the situation *has* changed, at least somewhat, but most of the
action is in compilers, not in hardware.  You don't need a level of
interpretation if you've got a really smart compiler, and you can compile
directly to fast RISC code.  (You may use a virtual machine, but it's not
really an interpreter---it's something like a dynamic compiler.)

  -- PRW

-- 
| Paul R. Wilson, runtime environmentalist          wilson@cs.utexas.edu      |
| U. of Texas Computer Sciences Dept.               voice: (512) 471-9555     |
| Taylor Hall 2.124, Austin, TX 78712-1188          fax:   (512) 471-8885     |
| "Inertia makes the world go 'round."              DoD M.C. # e  (Sz GS450T) |
Newsgroups: comp.arch