a tale of 4 cpus (was: CPU running smalltalk bytecode)
Jecel Assumpcao Jr
jecel at merlintec.com
Tue Feb 12 01:34:48 UTC 2002
Anyone interested in hardware implementation of OO languages should
read:
Do object-oriented languages need special hardware support?
by Urs Hölzle and David Ungar
http://www.cs.ucsb.edu/labs/oocsb/papers/oo-hardware.html
Here they contradict most of the results that David Ungar had obtained
in SOAR (Smalltalk On A RISC). Note that I happen not to agree with
their conclusions, but it is a good paper even so.
On Sunday 10 February 2002 19:50, Tim Rowledge wrote:
> Of course, there are still little problems like dealing with garbage
> collection and primitive stuff; making a hardware interpreter does
> nothing for these important areas.
True, but SOAR had hardware for write barriers (gc) and tag checking
(primitives). The paper I mentioned showed that these didn't help a
compiled system (jitter) much, but they might have more of an impact in
a simple cpu.
Though this is getting very off topic, let me describe the four
separate Self/Smalltalk cpu efforts I have been working on (one is
currently frozen).
- Oliver: a cheap embedded machine with small and narrow memories
(512KB of Flash and 8MB of SDRAM, both 16 bits wide). It is actually a
Forth cpu, but since this is an FPGA it will be an interesting
experiment to do a Smalltalk cpu on this board.
- Tachyon: a four bus MOVE processor with a fast external instruction
cache (http://www.merlintec.com/merlin6/merlin6c.gif) made from 768KB
of ZBT synchronous SRAM. Both the cache (96 bits) and main memory (64
bits) are as wide as possible to increase bandwidth.
> My take on things is that a possible and practical change in hardware
> that would benefit us (and many programs) would be an instruction
> cache that was precisely controllable by the programmer. A 2-4Mb
> i-cache that one could actually load the core vm into and _lock_ it
> in would be nice. An improvement on that might be to go back to the
> writable control store idiom, putting the vm 'above the bus'. A
> controllable d-cache might be useful in letting us make sure that
> recent contexts and important globals stay cached, stuff like that.
That is very much what Tachyon was like. Part of the i-cache contained
the VM (most of which was the bytecode->MOVE jitter) and was locked in
after boot. I think this is a very good design, but have stopped
working on it to do:
- Plurion: a set of simple stack machines that execute bytecodes
directly. I call this a "Snow White and 7 Dwarfs" architecture since
one cpu is more complex than the others and can do a set of
transformations on the code as it executes it (it is an interpreting
jitter, if I may coin a term).
I should mention that I have adopted the Self 4.1 bytecodes for my
designs. These are almost exactly the same as Ian's SAM (Squeak
Abstract Machine) bytecodes and are much more Smalltalk-like than the
Self 4.0 bytecodes. So Squeak could run on my hardware either by making
it run on top of Self (in the same way a Java ran on Self in the Jed
project, not how GNU Smalltalk ran on Self: binary, not source
compatibility is the goal) or by having a "half Jitter". Previously I
considered handling Squeak bytecodes directly, but there is a lot of
needless complexity in there and I don't have any PhD students handy.
> However as I've said again and again (redundantly even), it's
> bandwidth, bandwidth and bandwidth.
Very true, but the only real solution is to give up the Von Neumann
architecture entirely. So I am working on a fourth design which has
message passing at the transistor level. Would 4.8e+16 bytes per second
make you happy? This would be for a 1 million "cell" chip implemented
in 0.18 micron technology. This architecture can't be implemented in
FPGAs, unfortunately. I don't have a name for this one yet...
-- Jecel
More information about the Squeak-dev
mailing list
|