Re: Integrating a new front end to GCC - avoiding flames later

[Geoff Keating <geoffk at envy dot cygnus dot com>]

Tim Josling <tej@melbpc.org.au> writes:

> I just started coding the integration of a cobol front end to
> GCC. More details when I have something to report.
> 
> I have found enough documentation and samples to do this, but I
> would like to ask what issues I should consider if I want this
> integrated into the gcc mainstream later on. I am not talking
> about things I need to do to make it work, rather I am looking
> for things that people might object to down the track.
> 
> Here are some or the possible issues:
> 
> - ensure employer will sign waiver to allow copyright to be
> assigned to FSF

Please do.  It will make your backend much more useful as then
it can be integrated into the GNU compiler collection.

> - how important is it to use the gcc.c driver (assume not very as
> fortran does not) and the toplev.c main program, rather than
> parts of them in a new module.

Backends usually provide their own driver, like the programs
'gcc', 'g++', 'g77', and so on.  I expect that for COBOL you will
want to provide some kind of 'libcobol' to provide runtime
support, in which case you will certainly want a separate driver.

The drivers all share a lot of common code, you will want to look at
one of the other drivers (I suggest the g++ driver) to see how this is
done.

> - is it a problem if I have my own symbol table and only use the
> tree.h table for actually generating the code?

You should look very carefully into garbage-collection issues before
doing this.  The tricky bits are:

- If COBOL has global variables, which I expect it does, you will want
  to keep the trees for the variables around between function compilation.
  So you will need to be able to tell the GC that they are still used.
  This may mean you need to explain to the GC how your symbol table works,
  so it can find all the trees you have allocated.

- If you are using GC, you cannot allocate trees _without_ using the GC.
  This would cause it to crash.

- In the future, using GC may be mandatory.

> - Are there issues with {
>    indenting style;
>    variable naming:
>    etc;
> }?

There is a GNU coding guide for this.  It's reasonably good, at least
it's not bad enough to make it worth being different.

> - the directory structure and the makefile.in requirements.

You would put your project in gcc/cobol, probably, and you should
try to avoid (but see below) modifying stuff outside this directory.
Basically, look and see how the other backends do this.

> - is it important to manage memory tightly? GCC goes to a lot of
> trouble to do this, but is this necessary any more.

It depends.  Do your users typically have more than 2G of memory?  :-)

It's not necessary to be sure to free every byte as soon as you longer
use it, but it is important to make sure that you have any potentially
large structures which are allocated and never freed.

> - cobol has some data types like packed decimal with implied
> decimal point that are not directly supported in the back end. In
> the short term I woudl just define them as character arrays and
> use the existing data types and some custom runtime to support
> them. Some platforms do have hardware support though, especially
> mainframes. Long term what would be the attitude to adding new
> types to the back end vocabulary. This is a fair way off.

Yes, this often happens.  That's fine.  BCD support is one of the
things that GCC doesn't have yet, because so far no language has
needed it.

The m68k has hardware support for this.  I think the x86 machines do
too, although I'm not sure that it's fast.

> - are there any big changes coming that I should take into
> account (eg the garbage collection in the memory management)?

The garbage collection is here now.  You should also know about
tree-based inlining, which I think the C++ front-end now uses but the
C front-end does not.

There is no need to _not_ use garbage collection.  The C and C++ front
ends already require it.

-- 
- Geoffrey Keating <geoffk@cygnus.com>