On 11/16/2010 8:05 PM, Levente Uzonyi wrote:
> I wasn't clear when I said atomic code. I expected #= (and #<, #>, etc)
> to _not_ be a real message send when both the receiver and the argument
> are SmallIntegers. Otherwise what's the point of having separate
> bytecodes for them?

Space. It makes a big difference for the most common selectors (#at:, 
#at:put:, #size, #+ etc) to be be encoded as bytecodes. It avoids having 
to allocate a literal every time you see the selector. Often, the 
special selector bytecodes look like this:

Interpreter>>bytecodePrimNextPut
	messageSelector := self specialSelector: 20.
	argumentCount := 1.
	self normalSend.

I.e., it just dispatches to normalSend where the regular lookup takes 
place. Of course, that also means it's a prime place for an optimization 
that will evaluate eagerly for known receiver types and so (over time) 
optimizations were added, but many of the optimizations that may make 
sense in an interpreter have very different tradeoffs in the jit. For a 
jit to generate the level of optimization makes no sense because the 
code size simply explodes at no benefit if the inline caches are any 
good (ours *are* the best Eliot knows how to do and that is a meaningful 
statement).

On to a finer point. The terminology "real message send" is misleading. 
Generally, we (the VM hackers) mean by "real" send a send that requires 
a method activation, i.e., the creation of a context, but *not* the 
lookup of the method. That excludes for example all (successful) 
primitives from being "real sends", and as a consequence writing "1 + 2" 
is not a real send by that measure (with or without the bytecode 
present) since the primitive will be executed successfully and no "real" 
send (method activation) has taken place.

To make matters more complicated, when we talk about "real" sends in the 
context of thread switches, semaphores and critical sections, what we 
mean is whether there is a suspension point in the send or not. 
Obviously, some primitives (#suspend, #yield) must have suspension 
points so not all activation-free methods are also 
suspension-point-free. I am not entirely sure what the current set of 
rules for suspension points in Cog is; in the interpreter it was part of 
the activation sequence so any primitive that isn't process related 
would not have a suspension point but I don't know if that's still true 
in Cog.

Cheers,
   - Andreas