Integrating a new front end to GCC - avoiding flames later

[Tim Josling <tej at melbpc dot org dot au>]

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

- 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.

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

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

- the directory structure and the makefile.in requirements.

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

- 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.

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

- test suites

Speak now or forever hold your peace.

Tim Josling