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

Hi Corey,


> > 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.
>
> Well, sometimes its a bit set/fetch, which isn't an assignable
> address that can be handled like that. Based on the data type of
> the operand, different "get/fetch" calls are generated. I usused the
> simple "int" example, but others (int/long/float/char/bit/bitgroup
> and a few wierd ones) are possible.


Hmm. If they're all assignable by C, e.g. a bitfield can handle the
`bitgroup' you mention, then the above can be generalised by having a
union of all the different types and returning a pointer to the union.


        get_number_address(a, 1)->i = get_number_address(a, 0)->i;


Here's another alternative, based on it being an in-house language that
is open to change.


The current code is written in a language, lets call it A, that is
completely comprehended by your compiler which spits out C code.
However, suddenly saying that source written in A is really C source
with a few additions that your ex-compiler, now pre-processor, should
look out for, a la Ratfor, isn't straightforward as A was never
designed with that in mind.


So invent a new extension to C that is as easy as possible for your
pre-processor to grok and can handle all your existing requirements.
Call it C+A. This is also an opportunity to tidy up bits of A's design
that could be better with hindsight.


Write a new back-end for your A compiler that spits out C+A and turn
all your old A source into C+A source. Don't use the A source again.


You now have a load of C+A source that hopefully looks very similar to
the original A source in meaning, i.e. it isn't cluttered with lots of
C. Use the new pre-processor for C+A to generate C source for
compilation.


Cheers,


Ralph.

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