On Mon, 08 Jan 2001, Tim Rowledge wrote:

Great links, thanks!

> The key point I take from
> all these is that there is little point in trying to make a special CPU
> for Smalltalk (though the lessons don't appear to have been learnt by
> the java people yet).

Actually, Dave's thesis was that there were some interesting OO stuff
you could put in a processor. Most of these ended up in the Sparc. Then
Urs Hölzle (with him as an adviser) asked "Do object-oriented languages
need special hardware support?"
(http://www.cs.ucsb.edu/oocsb/papers/oo-hardware.html) and concluded
that the only thing that really helped was a large instruction cache.
This paper has some comments on why the results were different from the
SOAR project.

I don't agree with this:

  1) the hardware was designed after observing the output of C compilers
  2) the software was designed to run as fast as possible on the
hardware
  3) the software (Self compiler) was observed to generate the same
kind of code as a C compiler

How coud 3 be a surprise and an indication that special OO hardware is
not worth it?

I don't have much interest in trying to implement bytecodes directly in
hardware, however. But it might be worth it for very small designs -
see the ARM Jazelle stuff.

> My suggestion is that the key is to make a very, very fast memory
> system.

This is the key issue - all others pale beside this one. The Mushroom
tried to be fast by being smart. Just a small patch to the cache/mmu
system can allow the "new generation" to live entirely inside the cache
and to be garbage collected there.

> At one point it looked like TI might be onto an interesting idea
> when they announced some waferscale integration fab proces and commented
> that they could easily fit a few dozen StrongARM CPU cores and a few gig
> of ram on a wafer. Now _that_ would probably be quite a good ST machine.

This is my style as well, though you would have to convert Squeak into
a distributed system to take advantage of this.

-- Jecel