On 15-May-05, at 3:32 AM, Bryce Kampjes wrote:
>
> One problem with prims is they have to deal with a large number of
> receiver classes. I've changed my #at: implementation to use
> specialised primitives. You need to compile a version of the primitive
> for each receiver class that you use. That should be a good strategy
> for primitives like #at: and #new. Then all specialisation for the
> receiver class can be done at compile time.
>
> 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.

Until/unless you have inline caching, it might help you that the method 
cache now  (post 3.7b5 I think), see Interpreter 
 >functionPointerFor:inClass:) allows an arbitrary code pointer to be 
installed so that (for example) external prims are now directly cached 
rather than going via prim 117 every time. You could subvert the 
installation routine to cache the specialized version of the prim.

tim