Hi Jecel --

>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.

We called this the "giant hash table scheme" at PARC and thought 
about using some (future) VM hardware to look up this more useful 
virtual address for methods.

I'd love to hear how this works out (and what kinds of HW would do it 
better (like a specially programmed FPGA, etc.).

Cheers,

Alan

---------

At 03:50 PM 11/16/2006, Jecel Assumpcao Jr wrote:
>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