|Compile to C difficulties email@example.com (Charlie) (2006-09-08)|
|Re: Compile to C difficulties firstname.lastname@example.org (Michael Tiomkin) (2006-09-08)|
|Re: Compile to C difficulties email@example.com (Pascal Bourguignon) (2006-09-08)|
|Re: Compile to C difficulties firstname.lastname@example.org (George Neuner) (2006-09-09)|
|Re: Compile to C difficulties email@example.com (Charlie) (2006-09-11)|
|Re: Compile to C difficulties firstname.lastname@example.org (George Neuner) (2006-09-12)|
|Re: Compile to C difficulties email@example.com (Charlie) (2006-09-16)|
|Re: Compile to C difficulties firstname.lastname@example.org (russell kym horsell) (2006-09-18)|
|Date:||16 Sep 2006 15:55:28 -0400|
|Posted-Date:||16 Sep 2006 15:55:28 EDT|
George Neuner wrote:
> If I understand correctly, you've rewritten the DSL recursion in the
> form a threaded interpreter using an auxiliary data structure, and now
> use the real stack mostly for support functions.
Actually I use the real stack for all functions untill a LIMIT is
reached, and then use the auxiliary stack for "calls" between
functions within modules, while still using the real stack for calls
to support functions and to functions in diffirent modules. The LIMIT
is still a "guess-timation" and when it is set High the auxiliary
stack is seldom evoked, except for occasions I do not really
> While that certainly solves your stack overflow problem, I would bet
> it is a *lot* slower than directly executing the original recursive
> solution would have been (assuming you could). It probably also uses
> more total memory even though it uses less stack.
It does not seem to be much slower but I have not actually done
benchmarks. Most of my test cases are disk access intensive, which
would tend to hide the differences.
Also the greatest cost would seem to be reallocating the auxilliary
stack. (which also seems to mess up GC, which I tried to put in today
> If you can't eliminate the recursion, generating CPS might be the best
> solution. In CPS code a function call never returns, so the stack
> just keeps growing. You check the stack size before calling a
> function and when it gets too large, you copy the current call frame
> to the bottom of the stack and change the stack pointer ... thus
> freeing all the garbage on the stack at once.
I have seen references to something similiar in Scheme setting.
I do not really know how to do that in semi- portable C.
1) Record bottom of stack
2) memcopy a safe amount around current frame.
3) No Idea how change stack pointer.
References would be helpful
Do not really understand CPS in Gentle setting,
Functions not first class objects, more like Prolog or Mercury
which seem to do "trampolining"
Return to the
Search the comp.compilers archives again.