Integrating a new front end to GCC - avoiding flames later

[Jeffrey A Law]

  In message < 38667BDB.6C2D4497@melbpc.org.au >you write:
  > - ensure employer will sign waiver to allow copyright to be
  > assigned to FSF
Yup.  Similarly for other folks that contribute code to the project.


  > - 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.
It generally makes things easier.  You should look at the drivers
build for g++, g77 and the cpp wrapper.  They provide language dependent
front-ends to the (rather complex) generic code in gcc.c.


  > - is it a problem if I have my own symbol table and only use the
  > tree.h table for actually generating the code?
I'd probably recommend against this.   You should probably be building up
entire functions using the tree structures, then passing them off to
expand_expr to generate RTL.

  > - Are there issues with {
  >    indenting style;
  >    variable naming:
  >    etc;
  > }?
Definitely.  Start with the GNU coding standards (available on the
GCC web site).  That will cover a lot of this stuff.

  > - the directory structure and the makefile.in requirements.
Use the same general structure as other front-ends like g++ and g77.

  > - is it important to manage memory tightly? GCC goes to a lot of
  > trouble to do this, but is this necessary any more.
It's important to not leak lots of memory; as the front-end becomes more
robust and handles larger inputs, you may need to retune it to be more
memory efficient.  But the first goal is to build something that is clean
and maintainable -- then tune it as necessary.


  > - 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.
These types definitely need to be added to the tree structures; types
which have operations which directly map to instructions on common
hardware should also be added to the backend (for example BCD).

  > - are there any big changes coming that I should take into
  > account (eg the garbage collection in the memory management)?
Those are the biggies right now, though the basic infrastructure is mostly
done, we're in the process of expanding it to work with additional front
ends and such.

  > - test suites
Strongly recommended.  Use the c-torture/f-torture or the g++.old-deja
code as a basic framework to get you started.

jeff