Ramblings on how to optimize Squeak for modern CPU bit manipulation (Was Re: I was wondering ...

Tim Rowledge rowledge at interval.com
Sun Jul 4 04:59:57 UTC 1999


On Sat 03 Jul, Lawson English wrote:
> I hadn't thought the overhead-issue through properly, obviously.
> 
> There seem to be two possible approaches to get an *efficient* full-blown
> multi-byte "vector" processor in Squeak:
> 
> 1) create a built-in Obj-C compiler that will sidestep the overhead that
> you point out by converting all control structures and method calls into
> compiled Obj-C, while keeping the "vector" emulation portion in
> well-optimized, compiled C or vector-processor equivalent on a given
> platform (e.g. AltiVec, MMX, etc). This is obviously the most elegant and
> universal solution, but is beyond my capabilities.
As I've said quite a few times before, we (as in the royal-we) have an
extended CCodeGenerator available that could take modified slang (the
now-defunct-project-at-Interval-groups name for the psuedocode in
Interpreter etc) and generate machine object code either into a file of
direct to memory. It was mostly written by Alan Purdy, who knows a thing or
two about compilers. It is not exactly 'production ready', lacking some
work on optimisation and backends for anything other than StrongARM (but
who cares about any other processor anyway :-) ) but it has been known to
create an entire VM that ran.

It is available to anyone that wants to build new backends, work on
optimisations, whatever. It's not a trivial project. However, it is squeak
portable, Alan claims that new backends would be quite small and simple,
and it has the right price. I don't have time to care for it; does anyone
out there?

tim

-- 
Useful random insult:- One sandwich short of a picnic.
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