Re: Help and ideas with C-like to C transformation tool (long)

ralph@inputplus.demon.co.uk (Ralph Corderoy)
29 Dec 2001 13:30:33 -0500

          From comp.compilers

Related articles
Help and ideas with C-like to C transformation tool (long) Corey@Stup.net (2001-12-27)
Re: Help and ideas with C-like to C transformation tool (long) haberg@matematik.su.se (2001-12-29)
Re: Help and ideas with C-like to C transformation tool (long) rwaltman@verizon.net (Roberto Waltman) (2001-12-29)
Re: Help and ideas with C-like to C transformation tool (long) idbaxter@semdesigns.com (Ira D. Baxter) (2001-12-29)
Re: Help and ideas with C-like to C transformation tool (long) ralph@inputplus.demon.co.uk (2001-12-29)
| List of all articles for this month |

From: ralph@inputplus.demon.co.uk (Ralph Corderoy)
Newsgroups: comp.compilers
Date: 29 Dec 2001 13:30:33 -0500
Organization: InputPlus Ltd.
References: 01-12-162
Keywords: tools
Posted-Date: 29 Dec 2001 13:30:32 EST
Originator: ralph@inputplus.demon.co.uk (Ralph Corderoy)

Hi Corey,


> For another example, we have a rule for simple assignments. To
> reference a variable in our persistant store, you use a macro
> notation that gets transformed in the C-output based on if its a load
> or store operation. So in our language: (where the 'a' refers to a
> "file pointer", and the "n" refers to a datatype of "number")
>
> an(1)=an(0);
>
> Which means, set numeric array index 1 with the numeric value of
> array index 0, gets transformed into the C code as:
>
> storenumber(a,1,fetchnumber(a,0));
>
> Due to needing to know context to know if the action is a store or
> fetch, one can not just use 'm4' or a simple macro processor to do
> the pre-processing - one seems to need to know the context of the
> expression in the statement to do the transformation correctly.


If `an(x)' translates to `*get_number_address(a, x)' then your example
above becomes


        *get_number_address(a, 1) = *get_number_address(a, 0);


which lets the C compiler worry about context.


> A while-do construct in our language would be written as:
> WHILE an(standard_define)=TRUE DO
> /* ...work.... */
> ENDWHILE
>
> This gets translated into:
> while (fetchnumber(a,0)==TRUE) {
> /* ....work....*/
> }
>
> Which then is compiled by a standard C compiler.


Have you heard of Ratfor, the Rational Fortran preprocessor described
by Kernighan and Plauger in their excellent _Software Tools_? The
preprocessor only recognises certain constructs in its input, assuming
everything else is Fortran, and leaves the Fortran compiler to
determine this for sure.


It sounds like you want a similar approach.


> If I have to, I will add in the standard C grammar to our
> transformation tool as others have built lex/yacc versions that
> should integrate fine. However, this is a last resort, as I'd like
> to make this tool as SIMPLE as possible and leverage the most I can
> from the C compilers that have already been written and tested.


It does sound like the Ratfor approach is the right way to go.


> If anyone has any suggestions on a toolset to perform this type of
> task, please email or post followups to this post. I can provide
> more examples if anyone is interested.


A link to a manual of your in-house little language?


Cheers,
Ralph.
[Ratfor was useful, but to use it effectively you really needed to
understand both what ratfor did and what the underlying Fortran
language did, and have a rough idea of the Fortran that ratfor would
generate so the code you wrote wouldn't break ratfor's assumptions.
The guys who wrote ratfor went on to do EFL, Extended Fortran
Language, which was a full compiler that translated EFL into Fortran,
no default pass-throughs. -John]



Post a followup to this message

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