Where to next with Exupery?

Bryce Kampjes bryce at kampjes.demon.co.uk
Wed May 18 18:55:23 UTC 2005

tim Rowledge writes:
 > > I'll need to inline the specialised primitives to gain from the new
 > > #at: implementation (currently it's only 1.5 times faster than the
 > > interpreter). But that's a general framework that can be easily
 > > applied to other primitive operations.
 > I would have thought that you would be specializing for each _format_ 
 > not each class. #at:/put: typically would be distinct for byte/word/oop 
 > - unless of course you are going all the way to a special case for 
 > OrderedCollection distinct from one for Array?(A a poor example, 
 > admittedly) I suppose that might be plausible.

I'm specialising for each receiver class. The #at: primitive needs to
know how many named instance variables a class has to know where the
indexed instance variables start. By specialising for each class I can
do the named instance variable calculations at compile time.

I have polymorphic inline caches. So at each call site, I'm selecting
on the receiver class. I could register the same method for multiple
receivers but for now it's easier just to duplicate
them. OrderedCollection's #at: calls Array's #at:. A single compiled
version of the #at: primitive for indexed pointer objects
(Object>>at:) would need to reference the class to find out how many
named instance variables there were.

I've just started work on inlining the primitives, this will be the
first use of dynamic type feedback in Exupery. The reason for working
on this is Exupery's bytecode benchmark performance has halved due to
the new inlined primitives. They are more general and with inlining
should be faster than my atCache based implementation.

I'd like to incorporate Exupery's changes in the mainline VM but not
for another few releases. I'm still changing my VM modifications as
Exupery evolves. There will be more changes as I add support for
blocks and method inlining.


More information about the Squeak-dev mailing list