RISC42 [was: hardware for eToys]

Jecel Assumpcao Jr jecel at merlintec.com
Thu Nov 16 23:50:04 UTC 2006


Klaus D. Witzel wrote on Wed, 15 Nov 2006 05:40:06 +0100
> I like the LOGIC/KLOGIC instruction, it looks like a friend of BitBlt :)

That is the idea, though perhaps a KSHIFT/LOGIC combination (which the
ARM can also handle) would be even more important for the graphics
primitives.
 
> How would Smalltalk's method lookup routine look on RISC42?

This design was created for running C, not Smalltalk. So the answer is
that it would be just the same as on any other generic RISC. That said,
it would be nice to run SqueakNOS on this. A teacher at a local
university was trying to put together a project for creating an open
source RISC code with his students and that inspired me to come up with
this, but the idea is that they would do the actual work of implementing
it.

The designs that I *am* working on are optimized for Smalltalk. The
current 16 bit version (http://www.merlintec.com:8080/Hardware/Oliver)
essentially has a vast table of all class/selector combinations. Each
table entry is two words long and holds the actual instructions for the
corresponding method. So you just have to do "call
table[class(receiver),selector]" which, not counting cache misses, can
be executed in a single clock cycle (the "class(receiver)" function
doesn't involve a memory access since I use a variation of the class
encoding scheme from Smalltalk-74's OOZE). The bulk of the table entries
(over 80%) are for invalid class/selector combinations and their code is
just a jump to the MNU routine. Many other entries are for very short
methods that fit in the two words. For longer methods the table entry
has a jump to the rest of the method (since it is "long" anyway, the
overhead of the jump won't be too bad).

This scheme wastes memory, but I happen to have 8MB on a machine that
would work just fine with 2MB or less. So I have 6MB that would be
useless otherwise and wasting them to save a few clocks per message send
is a great option.

For a 32 bit Smalltalk this wouldn't work. The Squeak 3.8 image I am
typing this in has 2339 Metaclasses and 40849 ByteSymbols, and so would
need a table with 95 million entries (764MB if each entry has two words
of 32 bits each). So for that case I have an alternative called "PIC
Mode". I should put a description of this on my swiki, but basically it
scales far better and allows type feedback for optimizing compilers but
sends take a few more clocks than in the 16 bit version (hopefully
inlining eliminates many sends and makes up for that).

-- Jecel



More information about the Squeak-dev mailing list