Re: Compile to C difficulties

George Neuner wrote:
> On 8 Sep 2006 16:56:43 -0400, "Charlie" <chpowell2002@yahoo.com>
> 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; ... ;
Module_A(PROCEDURE_NUMBER);
                              *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.

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