Re: Compile to C difficulties

"Charlie" <>
11 Sep 2006 23:59:44 -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: 11 Sep 2006 23:59:44 -0400
References: 06-09-02606-09-031
Keywords: C, storage
Posted-Date: 11 Sep 2006 23:59:44 EDT

George Neuner wrote:
> On 8 Sep 2006 16:56:43 -0400, "Charlie" <>
> wrote:
> >Jenny/Jenagin is implimented 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 ...
> >
> >Currently I am working on improved translation to C.
> Stack limits on most systems are pretty liberal (see below) so if the
> stack is routinely overflowing, I would work seriously on eliminating
> recursion in the generated code.

The Core of the entire project is a high level semantic specification,
with recursion used throughout. Removing recursion,( or more properly
induction), is not a real possibility, although in isolated cases I
have done so by evoking generated code in C while loops. Translating
to a language other than C, say to Mercury, would be a better option
if it comes to that. Hovever Mercury itself is translated to C.

> Your options are limited if you insist on compiling to C. The best
> solution is to generate code that does not overflow the stack in the
> first place. If you can't guarantee that, you can ...

> The real stack has the same problem ... C just doesn't know about or
> support GC and few (if any) C compilers bother to reset pointer
> variables after their last use. ...

This is very useful information, I currently do not use a GC, but
anticipate using Boehm or another GC or writing my own as a last
resort. later in the project.

> WRT Boehm, I don't know exactly what you are doing, but from your
> comments I am guessing that you are allocating an array on the heap
> and manipulating the CPU stack pointer to switch to/from it. One
> thing you can try is starting your application with GC disabled,
> allocating your stack array in an uncollected heap, then enabling GC
> and using GC_add_roots()/GC_remove_roots() to control what parts of
> the stack array are scanned.

I am not actually manipulating the CPU stack pointer,
( I would not Know how to do that in semi portable C )
I am reading it and testing it, something roughly like

    PROCEDURE(yy Input1, yy Inupt2, yy * Output3 )
        int abc; void * sp=&abc; ....
          if( sp>LIMIT){ MY_STACK[SP+1]=Input1; ... ;
                              *Output3=MY_STACK[SP+3]; return ;
        else { Regular procedure code }

where Module_A is a single procedure with a switch on PROCEDURE_NUMBER
to a goto to begining of Procedure Code, evoking other procedures
within the module with gotos, setting a procedure occurance return
number on the MY_STACK, used by an even larger switch with a case for
each procedure occurance. Inside the Module Procedure variable passing
occurs on MY_STACK. Procedures in other modules,
and C procedures are evoked normally. Assuming no recursion between
procedures in different modules, recursion in contained.

All more or less portable C and it is working with reasonable speed.
My problem is determining a good LIMIT. Currently the best option seems
to be to select one that
seems to work for each system/compiler and allow the user to adjust if
greater speed is desired, at risk of over flow and/or slow virtual
memory. A concern I would rather not burden the user with.

Similiarly on GC, I could have an adjustable uncleared range which I
could check before evoking GC_malloc, clearing MY_STACK if the size
gets too large.
If need be perhaps this could be done with system stack.

Also I could try some Tail/Last_call optimization

Again Thanks for all the advice.

Post a followup to this message

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