Hi,

> I've been looking at commonReturn and started to wonder why 
> the usage of
> 
> 	localCntx _ localReturnContext.
> 	localVal _ localReturnValue.

Mostly because I wasn't sure if all compilers will be able to recognize that
these values are in fact used read-only for the branch. E.g., a "lesser
compiler" might not look at the branch individually and just say "well that
gets read and written all over the places so I won't even try to optimize it
into registers". If you got a smart compiler then the first thing it'll do
is to recognize that this really *is* an alias and no bad things will happen
as a result. Or at least that's what I think ;-)

In addition, I wanted to be able to play around with making these variables
global and that may hurt PPC and others as long as there aren't any explicit
hints given that these values should be kept in registers (see all those
"keep in register" comments spread out through interpreter).

> You see with the current VMMaker any sole usage of a instance 
> variable in Interpreter will get folded
> into a local variable versus a global if all references to that  
> instance variable inline into a single C procedure.

WHAT??? Are you trying to tell me that if I add an instance variable to
class Interpreter which is only used in a single method (most likely
interpret()) it will automatically become a temp of that method? Where can I
turn this off? I don't want it - it's bad, bad, bad! Global variables are
cheap, stack relative addressing is expensive if your registers are already
cramped up with localIP,SP, etc.

> However I'll point out that GCC and codewarrior with
> optimization decides we are idiots and ignores
> the localCntx/Val constucts because they are read only and 
> fold back to the localReturnContrext/Value

Which is exactly what a good compiler _should_ do ;-)

> I did create a change set to do this, but then in doing this 
> I reviewed the usage of externalizeIPandSP and decided one of
> the main usage is to avoid issues with positive32BitIntegerFor:

I don't understand you. What issues are you talking about and why is it the
"main" usage? Both, externalizeIPandSP as well as internalizeIPandSP are
used to transfer state between interpret() and the rest of the system so
that whenever we get out of interpret() we can still refer to the
instruction pointer and the stack pointer. I don't see what this has to do
with #positive32BitIntegerFor:.

> Which points to considering inlining the bit bytecode 
> primitives, and primitivePointX & primitivePointY

Do you have any benchmarks that show the effect? I hate adding complexity
without actually improving anything.

> Also this brought back another memory, I'm sure Anthony 
> (years?) back pointed out that usage of
> instantiateSmallClasssizeInBytesfill results in filling the 
> allocated object with 0 or nil, but then we just fill the object with 
> data right right away, this is silly. Think we could follow thru on
> his idea?

Well, I think we may want to consider a new primitive which is capable of
allocating bit objects without initialization (how about #primitiveDirtyNew
;-) The code could be used in those places where we care on the VM-level
such as float or large integer allocation. BTW, I'm no big fan of making
this the default for bit objects - it gives you the ability to read
arbitrary memory from Squeak and that's a big security risk (think about a
situation in which we just entered a password and afterwards we simply
allocate a huge chunk of memory and search for this password). If we add
this ability it should be the exceptional case and not the default.

And again, before doing anything alike I want to see benchmark results.

> And why does signed32BitIntegerFor: use instantiateClass, versus   
> instantiateSmallClasssizeInBytesfill?

At the time I wrote this, it had (literally) no users. Certainly not in any
critical places. If you can show me some improvement in any benchmarks you
devise we can certainly change it ;-)

Cheers,
  - Andreas