Related articles |
---|
Compile to C difficulties chpowell2002@yahoo.com (Charlie) (2006-09-08) |
Re: Compile to C difficulties tmk@netvision.net.il (Michael Tiomkin) (2006-09-08) |
Re: Compile to C difficulties pjb@informatimago.com (Pascal Bourguignon) (2006-09-08) |
Re: Compile to C difficulties gneuner2@comcast.net (George Neuner) (2006-09-09) |
Re: Compile to C difficulties chpowell2002@yahoo.com (Charlie) (2006-09-11) |
Re: Compile to C difficulties gneuner2@comcast.net (George Neuner) (2006-09-12) |
Re: Compile to C difficulties chpowell2002@yahoo.com (Charlie) (2006-09-16) |
Re: Compile to C difficulties kym@ukato.freeshell.org (russell kym horsell) (2006-09-18) |
From: | "Charlie" <chpowell2002@yahoo.com> |
Newsgroups: | comp.compilers |
Date: | 16 Sep 2006 15:55:28 -0400 |
Organization: | Compilers Central |
References: | 06-09-02606-09-055 06-09-061 |
Keywords: | C, code |
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
understand.
>
> 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
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"
>
> George
Thanks Charlie.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.