Why so few garage processors? (was Re: Squeak History / TinyMachines)

Tim Rowledge tim at sumeru.stanford.edu
Thu Mar 20 19:45:02 UTC 2003


Torsten Sadowski <moehl at akaflieg.extern.tu-berlin.de> wrote:

> You should find out first, if building a whole new processor is necessary
> and viable. I have collected quite a number of articles about OO
> processors including the Xerox machines, Recursive(both SuperCISC) and
> SOAR(RISC). There are also some Java processors around. It seems that the
> difficult problems are OO storage and method finding whereas the actual
> bytecode-interpreter is a bit more simple. 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. Language requirements change
> and processors are rather static which might lead to dead ends as CS goes
> on.
This is a real problem. Let's imagine that somebody had implemented a
cpu that could do a wonderful job of running squeak bytecodes (and
prims, and gc etc etc, not an easy task but we're in fantasyland anyway)
and now let's imagine that we've decided some extra or changed bytecodes
or prims are crucially important. We're screwed. Whilst changing a cpu
design can be done it tends to be a little time consuming and expensive.
If, and this is a very big 'if' in large flaming letters visible from
other galaxies, this were a mainstream processor supported by a huge
company with massive resources then it might be possible to support such
a device. But it isn't and probably won't be. The basic conclusion from
most of the language specific cpu projects is that it isn't worth it in
the end because the general purpose cpus advance faster and always end
up doing better over all. Of course there is a bit of a joke in there
because 'general purpose processor' is _actually_  'C language
processor' these days. Thank goodness C is little more than a jumped up
PDP-8 assembler or we'd probably have a lot more trouble doing things
we're interested in.


> In my opinion it might be interesting to have two memory buses. One very
> fast (at processor rate) running the VM and a slower for the image. There
> is an inherent bandwidth preservation in bytecoded languages.
Excellent observation. I've said for years that we need three things
for Smalltalk performance - memory bandwidth, memory bandwidth and
memory bandwidth.

My feeling is that the real architectural winner for many languages like
Smalltalk (I guess we could include PDF, Lisp, Prolog etc) would be a
decent amount of cpu-private memory above the external bus that can be
completely controlled by software. Not 'cache' since that is always
trying to guess what you want and seems to get it wrong too often - and
costs lots of control logic as well. No, I want something very like a
writable control store, memory that I can load routines into and crucial
variables so that I never have to spend time on the outside bus. I
suppose that actually being able to implement sort-of instructions would
have some value as well, but I'll happily accept the simpler option. The
ancient NatSemi 'Clipper' of the mid 80's had something like this, I
think they called it above the bus memory, but unfortunately the rest
of the cpu was disappointing.

Interestingly, the latest ARM architecture (v6) provides for a small
amount of this tightly coupled memory or 'TCM'. 64Kb is not enough
really but better than nothing. I'd really like to make something
broadly similar to an ARM but perhaps drop the conditional instructions,
double the registers, have a meg or two of TCM etc. Languages like
Smalltalk tend towards very short linear runs on the code by comparison
to C, so very efficient subroutine stuff is important along with fast
context switching. Many processors take a long time to context switch
because of large caches needing to clear. Ideally though the big
improvement would be faster random access memory so we don't need
traditional caches. MRAM offers some hope in this direction.

Like I said, gimme money and you can have it.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- Not an idiot, but plays one in his life.



More information about the Squeak-dev mailing list