Re: Compile to C difficulties

"Michael Tiomkin" <>
8 Sep 2006 23:20:34 -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: "Michael Tiomkin" <>
Newsgroups: comp.compilers
Date: 8 Sep 2006 23:20:34 -0400
References: 06-09-026
Keywords: C, storage
Posted-Date: 08 Sep 2006 23:20:34 EDT

Charlie wrote:
> I am developed a language, Jenny (see -- which may be of
> interest to the members of this group. Jenny/Jenagin is implemented
> with a version of Gentle, which compiles to C in a simplistic fashion.
> Since many of the rules are recursive, the C procedure stack can
> overflow for practical exam code.
> Currently I am working on improved translation to C. To avoid C stack
> overflow, I can use my own stack from heap memory but this slows the
> execution. So I can run normally with the C stack, then switch over
> to the heap stack. In the literature I have found a means of
> determining position on the C stack which should be fairly portable,
> and can switch over once a arbitrary limit is reached.
> But for robust usage I have a number of questions.
> Is there a reasonable way to obtain a good limit?
> I considered trying to probe the stack size with say alloca but this
> seems to exit the program when the limit is reached.
> If the C stack competes with the Heap space or grows into virtual
> memory, is this even a good idea?

    On some systems this is true. For example, on Windows every
process/thread has a fixed maximal stack size, but a one-thread process
can have a significant part of available memory used for stack. There
are some reasons for using a usual stack and a heap stack:

1. For a usual stack you only use the memory you need, without the

2. For a heap stack, there is overhead of two words for every item,
one for the heap management, and the other for your stack management.
However, for some automatic variables, you can allocate them much
later in a function, and free them much earlier, making the stack size

    I think you can first try to enlarge the stack size (a linker option)
and/or check your programs for infinite resursion - this is what you
get instead of usual infinite loop in functional programming.

> Any suggestions?

    If you only have a few functions that are used recursively, you can
try to change your C code to use tail recursion. Inlining some of the
functions can help in this case. When you feel that you are ready to
use inlining/tail recursion, you can find the right C compiler options
to do that.


Post a followup to this message

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