----- Original Message ----- 
From: "Hans-Martin Mosner" <hmm at heeg.de>
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Tuesday, October 23, 2007 1:50 PM
Subject: Re: [vm] Large Frame size


> Rob Withers schrieb:
>> I have a need for a larger frame size.  I am defining internal temps
>> for some changes I am making with macro transformations, and I ran
>> into the limit of the frame size when compiling some method in the
>> image.   So what would be a good frame size for the large frame?
>> Could someone guide me as to what I would need to change in the vm to
>> support this?  Will I need to use the SystemTracer to get an image
>> prepared for using them and avoiding problems with the old large frame
>> size going away?
>>
> An easier solution might be to modify the compiler to stuff some temps
> into an Array and generate code to access that Array where you would
> normally generate temp var accesses. That way, you don't have to change
> the VM, and the cost would only be paid for the very few methods
> exceeding Squeak's large frame size.

That's a very interesting idea.  When/Where could I initialize the array?

I dug deeper and found some interesting things.  It is not just the internal 
temps that I am defining that is creating the need for more frame size.  I 
am also increasing the depth of the stack needed, as code that once was 
macroed, is now a first class message send, and so are pushing args onto the 
stack.   This seems to get worse with nested calls for some reason.

For example, in the GeniePlugin, the method 
#primSameClassAbsoluteStrokeDistanceMyPoints:otherPoints:myVectors:otherVectors:mySquaredLengths:otherSquaredLengths:myAngles:otherAngles:maxSizeAndReferenceFlag:rowBase:rowInsertRemove:rowInsertRemoveCount: 
normally generates nTemps: 50  and stackDepth: 6, exactly the large frame 
size.  With the code changing the macro transforms on, it generates: nTemps: 
50  stackDepth: 15.  Finally with the macro temps turned on it generates 
nTemps: 63  stackDepth: 15.  This seems to be due to nested #to:do: calls 
with #ifTrue:ifFalse:, both of which I am transforming.

So, even without using macro temps, I am still looking at a frame size of 
65, exceeding the large frame size of 56.  The max is 78.  I think I'll work 
on defining a frame size of 80, as a nice round number.

Will I need to use the SystemTracer to make this change, or will it create 
the right size contexts when I run an image file?

Cheers,
Rob