Oops. The previously attached message didn't make it. Ray -------- Original Message -------- Subject: Re: [cmucl-imp] Fwd: Re: Frame size for local calls Date: Sun, 09 Jan 2011 09:46:23 -0500 From: Rob MacLachlan <ram@ri.cmu.edu> To: Raymond Toy <toy.raymond@gmail.com> It doesn't seem that my attached message made it through to the list when you forwarded it. Here it is inline. Rob __________________________________ On 1/4/2011 9:09 AM, Helmut Eller wrote:
The comment for the ALLOCATE-FRAME vop reads:
This is emitted directly before either a known-call-local, call-local, or a multiple-call-local. All it does is allocate stack space for the callee (who has the same size stack as us).
Does that mean that all local calls in a component use the same frame size? Isn't that wasteful?
Yes, it does mean that. And it does waste some space, but not time, since it takes the same amount of time to allocate any amount of (uninitialized) storage. Unless you have a huge non-tail recursion, stack usage is likely to be in the 10's of kbytes range, which was not a big concern for me, even on a machine with 4 meg of memory. You could avoid this by generalizing the register allocator to know about frames, or by doing local call in some other way. Also, the register allocator deliberately wastes stack space by allocating stack storage in larger chunks, under the theory that this will make it more likely that the source and destination of a move can be packed in the same location, eliminating a memory-to-memory move. I think that what has proven to be the biggest adverse consequence of this stack wastage is that it makes dead pointers appear to still be in use because they were referenced by some stack slot that was allocated, but is never used by that function. Of course, this could happen even if all of the stack slots were potentially used somewhere inside the function, since they still might not happen to be live at the time of the call. Rob