Hi Nicolai,
the stack starts as deep as the method's number of temporaries, which is
the sum of the number of arguments plus the number of temporary variables that
can exist in the stack plus one if there are any closed-over temporary
variables that need to be in an indirection vector. Then as execution proceeds
the receiver and arguments are pushed on the stack, and are replaced by
intermediate results by sends it by the create array bytecode. Any blocks
within the method start with the sum of their number of arguments, their number
of copied values (temp values they access read-only) plus their local
temporaries.
In the method and each block scope stack depth is the hence the sum of the
number of temporaries plus the max execution depth. And the method's depth is
the max of the method and that of any blocks within it. Then if that depth is
17 or greater it gets the LargeFrame flag set which means the VM allocates a 56
slot context, the compiler raising an error if the depth is greater than 56.
HTH
Eliot (phone)
On Aug 18, 2014, at 11:32 PM, Nicolai Hess <[email protected]> wrote:
> Hi,
>
> on what depends the stack size for a compiled method?
> I try to figure out, why the old compiler and the opal compile generate
> different
> compiled method headers.
> I think this comes from a wrong stack size computed by opal, but I can not
> figure
> out how the stack size is computed.
>
> Old Compiler
> PolygonMorph>>#lineSegmentsDo:
> header -> "primitive: 0
> numArgs: 1
> numTemps: 3
> numLiterals: 23
> frameSize: 56"
>
> Opal compiler:
> PolygonMorph>>#lineSegmentsDo:
> header -> "primitive: 0
> numArgs: 1
> numTemps: 3
> numLiterals: 23
> frameSize: 16"
>
