Tail call elimination

Christopher Wright dhasenan at gmail.com
Thu Dec 4 15:12:22 PST 2008


Nick Sabalausky wrote:
> "Christopher Wright" <dhasenan at gmail.com> wrote in message 
> news:gh759s$2ucs$1 at digitalmars.com...
>> Nick Sabalausky wrote:
>>> On a side note, stack overflows are still possible anyway (whether 
>>> functional or imperative). Is there a reason (other than inertia) that 
>>> stack frames aren't set up like a dynamic array to grow as needed? (Of 
>>> course, I can understand not doing that during a debug build to help 
>>> detect unintentional infinite recursion) I realize the overhead of 
>>> checking the stack size on every function call might be undesirable, but 
>>> (not that I've given this much thought) is there no trick to set 
>>> something up to automatically trigger when the stack fills up? Or, isn't 
>>> it already detecting stack overflow anyway (I know some languages do 
>>> that)? (Of course, I'm not saying any of this would be a substitute for 
>>> TCE, just a good compliment to it.)
>> You allocate memory whenever you overflow the currently allocated stack. 
>> The caveat is that it has to be contiguous to the existing stack 
>> (virtually contiguous, not physically contiguous). In the best case, as 
>> soon as you allocate something outside the stack, you've set a limit on 
>> the stack size.
>>
>> On Linux, if your stack exceeds its allowed size, you get SIGSEGV. You can 
>> trap this, but you need to specify an alternate stack to do so. On my 
>> machine, the default stack limit is 8MB, though you can change that. I 
>> assume that setting the limit will alter the ranges that heap memory 
>> allocation can deal with, as well.
> 
> I see, so a relocatable stack would be required, and I can see how that 
> would be a problem. Is it (at least in theory) possible to use paging tricks 
> to transparently move the stack to a location with more available space 
> (perhaps with the cooperation of both the OS and the GC)? 

If you required a physically contiguous stack that could be logically 
noncontiguous, yes. You need a logically contiguous stack that does not 
need to be physically contiguous, though, so that fails. You'd have to 
change pointers.



More information about the Digitalmars-d mailing list