At 09:06 AM 2/20/99 -0800, you wrote:
>On Sat 20 Feb, Andrew C. Greenberg wrote:
>> Tim suggests:
>> 
>> > There are some bits available in the method headers
>[snip]
>> 
>> Isn't the idea to avoid things that increase the overhead of message 
>> send?  Is the feature of precluding primitives at runtime (since 
>> compile-time is relatively straightforward) so valuable a feature 
>> that it justifies a separate check against a method header flag for 
>> EVERY uncached message send?
>Definitely we avoid adding unneccessary cycles to message sending.
>I'm not quite sure about your 'precluding primitives at runtime' snetence
>means, so forgive me if I get the wrong end of the stick!
>
>My suggestion would add a simple check to the code that already checks
>the method header, and if the flag(s) is set, it would ORR in an extra bit
>to any primitive index from the header. Thus primitive 71 might be put in
>the cache as primIndex 16r10047 instead. Indeed, since my
>NewCompiledMethod images have cleaned up the arrangement of primitive bits
>in the header, this change would probably cost nothing overall! The the
>exectureNewMethod routine would include a test for the 16r10000 bit and
>check the equality of sender and receiver if required - which would cost a
>couple of cycles per send on average.
>This would work equally well for methods with primitives or without, even
>for special return primitives.
>
>So, it is as always a balance between function and performance. Is enforcable
>runtime privacy worth a couple of cycles added to a two or three hundred
>cycle send routine? What do people think?
>
It depends.  If you assume that Squeak will continue to have a two to three
hundred cycle send routine, then your addition will make little difference.

I would like to see Squeak's method dispatch eventually 
generate code similar to:

    test oop, 1, dispatchInteger         ;Test for integer (and, branch if
not 0)
    load [oop + #classOffset] -> r1      ;Load actual class
    load [method + #someOffset] -> r2    ;Load predicted class
    load [method + #someOffset+4] -> r3  ;Load stored method to call from
"inline" cache
    call r3 + #codeOffset                ;Call actual metod
       ..in steart of method...
    cmp  r1, r2                          ;If the predicted and actual
classes are 
    jne  inlineCacheMiss                 ;different then redispatch using
method cache
       ..continue with method code...

(The instructions should be rearranged to place loads as early as possible
 relative to when the load is used.)

We are a ways away from this.  It would require both a more streamlined
object header, a different method of dispatching primitives, and native
compilation.  Of course, someday it would be nice to go even beyond this
with a Self-style highly optimizing compiler.

So, if you are considering adding something that will complicate method
dispatch,
you might consider the complexity it would add to an optimized method dispatch
rather than the one we have now.

Greg Gritton

>The VM changes are trivial; couple of hours work at most, but it would be
>a bit more thinking to do a clean image/parser/compiler interface.
>tim
>
>-- 
>Useful random insult:- Has nothing to say, but delights in saying it.
>Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 842-6110 (w)
> tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>
>
>
>