Re: Compile to C difficulties

"Charlie" <>
16 Sep 2006 15:55:28 -0400

          From comp.compilers

Related articles
Compile to C difficulties (Charlie) (2006-09-08)
Re: Compile to C difficulties (Michael Tiomkin) (2006-09-08)
Re: Compile to C difficulties (Pascal Bourguignon) (2006-09-08)
Re: Compile to C difficulties (George Neuner) (2006-09-09)
Re: Compile to C difficulties (Charlie) (2006-09-11)
Re: Compile to C difficulties (George Neuner) (2006-09-12)
Re: Compile to C difficulties (Charlie) (2006-09-16)
Re: Compile to C difficulties (russell kym horsell) (2006-09-18)
| List of all articles for this month |

From: "Charlie" <>
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

> 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"

> George

Thanks Charlie.

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.