oo hardware (was: Why so few garage processors?)

Jecel Assumpcao Jr jecel at merlintec.com
Thu Mar 20 23:53:46 UTC 2003


On Thursday 20 March 2003 07:49, Torsten Sadowski wrote:
> [...] My personal interest faded when I realized how much work it
> would be and when I read an article by David Ungar "Is Hardware
> Support for OO Languages really necessary". He says no and he was one
> of th main designers of SOAR.

I really recommend the paper you mentioned to anyone interested in this 
thread:

  http://www.cs.ucsb.edu/labs/oocsb/papers/oo-hardware.html

While Urs Hölzle did a great job, in my opnion the question he really 
answered "no" to was "does patching a processor optimized for C help OO 
languages?"

People looked at the output of C compilers and then created the best 
possible chip for running that. Urs looked at this processor and then 
created the best Self compiler for that. Finally, he looked at the 
things that had made a large difference in SOAR (tagged integer math 
instructions, register windows, etc) and noticed that the output of the 
Self compiler was so similar to that of a C compiler (duh!) that they 
wouldn't help here. Only a larger instruction cache (of course - with 
dynamic translation we trade off memory for speed, so more memory 
helps) and a different data cache policy made a difference.

But suppose that you were not limited to tweaking. If you could adopt 
the virtual object cache of the Mushroom project, for example. Like N. 
Vijaykrishnan did for a Java processor in his PhD thesis 
(http://www.cse.psu.edu/~vijay/dissertation.ps). Then you might have a 
very different result.

> Language requirements change and
> processors are rather static which might lead to dead ends as CS goes
> on.

Alan already commented on the need to stay flexible. And certainly it is 
a bad idea to hardwire the state-of-the-art garbage collector or 
something when somebody will come up with a far better idea soon that 
can beat your solution when implemented in software on a stock 
processor.

But the real tragedy for language specific processors are simply the 
difference in resources. Even Motorola can't seem to keep up with 
Intel, so why should a small academic (or start up) team be able to?
You start your project in 2003 thinking you will get 8 times the 
performance of the Pentium IV 3GHz with your little bag of tricks. But 
in 2006 you will still be working on exactly the same design and what 
will Intel have out by then?

Now suppose you can get a competitive solution working on an FPGA. If 
somebody comes up with a better idea, just patch your VHDL and 
recompile! And you get to ride Moore's law like all the big guys since 
faster and cheaper FPGAs will be coming out every year.

-- Jecel



More information about the Squeak-dev mailing list