Optimizing Squeak

Tim Rowledge rowledge at interval.com
Wed Feb 24 19:46:36 UTC 1999


On Wed 24 Feb, Eliot & Linda Miranda wrote:
[snip lots of good stuff]
> One last point; native code requires instruction cache flushing when
relinking sends o
> n many processors.  It used to be the case that one could write extremely
efficient ca
> che flushing logic in the form of a jump table.  One would pre-gen
> erate a jump table big enough to shadow the icache and then jump into it at
the point 
> that matched the send instructions being flushed.  Hence to flush the cache
on would s
> imply execute a few nops and a pair of jumps (e.g. this works for 
> 68020 & 68030 processors).  icache designs are now much more complex (e.g.
the 68040 h
> as a 4 way set associative icache with a random replacement
> policy) meaning that one has to use the official route.
....and sometimes the official route is slow, difficult or even wrong(!) - for
example:-
 flushing the cache on a StrongARM can cost ~2k cycles
 between two versions of the IBM RS6000, flushing changed from a fast
instruction to a faulted library call
 between two revs of Sparc, the flush instruction changed from specifying
(IIRC) a closed interval to a semiopen interval and so we (PPS - I was there at
the time) were 'missing' flushing one word and thereby excuting (sometimes) a
wrong instruction.

You can have a lot of fun with such changes....

One potential benefit of staying with threading is that you are typically
generating addresses as data rather than instructions as data which doesn't
cause quite so much confusion in the caching. As Eliot mentioned it's also a
much simpler porting process.

And of course there is always the topic of Ian's PhD thesis, generating native
directly from the Smalltalk compiler. Now that our machines need 128Mb ram just
to boot the OS, the space costs of this approach seem somehow less worrying!

tim

-- 
When we write programs that "learn", it turns out we do and they don't.
Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 842-6110 (w)
 tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>





More information about the Squeak-dev mailing list