On 2012-06-21, at 17:55, Nicolas Cellier wrote:
> OK, but with the LargeFrame = 56 limit, I cannot compile a method written
> 
> ^1+(1+(1+(...  64x times )))
> 
> or I get an Error triggered by:
> 
> CompiledMethod>>needsFrameSize: newFrameSize
> 	"Set the largeFrameBit to accomodate the newFrameSize"
> 	| largeFrameBit header |
> 	largeFrameBit := 16r20000.
> 	(self numTemps + newFrameSize) > LargeFrame ifTrue:
> 		[^ TooDeepStackError signal: 'Cannot compile -- stack including
> temps is too deep'].
> 	header := self objectAt: 1.
> 	(header bitAnd: largeFrameBit) ~= 0
> 		ifTrue: [header := header - largeFrameBit].
> 	self objectAt: 1 put: header
> 			+ ( ((self numTemps + newFrameSize) > SmallFrame or: [ self
> primitive = 84 "perform:withArguments:"])
> 					ifTrue: [largeFrameBit]
> 					ifFalse: [0])
> 
> To overcome the limitation, I would have to re-arrange the order of
> push/sends. Since I can't easily guess absence of side effect in
> Smalltalk, I can't reorder.
> So I would have to push in a temporary array rather than in a stack
> (simulate a stack), then push (array at: i) on demand just before
> sending (I think the closure bytecodes also provide some short form).
> Phew...
> 
> Nicolas

That sounds way harder than pulling out subexpressions into hidden temp vars. E.g.,

	^ 1 + (2 + (3 + 4))

is exactly equivalent (same order of message sends) to

	| t1 t2 |
	t1 := 3 + 4.
	t2 := 2 + t1.
	^ 1 + t2

If the temp number limit was lifted this would be the way to go, I think.

- Bert -