M3 and gcc/egcs (was: Re: gcc-2.8.0 mailing list ?)

[Jeffrey A Law]

  In message <Pine.OSF.3.95.971228231257.18838K-100000@kralle.zdv.Uni-Mainz.DE> you write:
  > > >> It's not quite _that_ ancient.  The code generator is based on GCC
  > > >> 2.6.3.
  > > >
  > > >Ooops. Mea Culpa. I should have looked at it again.
  > > 
  > >  I think polymtl M3 has a more recent backend, but don't quote me on 
  > > that..
Well, gcc-2.6 is so old I can't even remember any distinguishing features...

gcc-2.7 is about 2 years old, still ancient by my standards :-)

There's probably a significant amount of work involved with just bringing
it up to a reasonable code base.  I can't take on any more work, but I am
willing to provide guidance if someone wants to start to bring M3 into
the egcs era.

  > >  Yes. It would be nice, but it would also probably be a lot of work,
Probably.

  > > probably wouldn't be supported
Depends on what state it's in and whether or not the M3 developers want
to support it.


  > > (I presume the frontends need to be
  > > written in C/have the same general invocation requirements/whatever
  > > to be supported ?),
This used to be the case, but I suspect we'll start to relax this 
restriction as we start thinking about how to integrate Ada (which
is written in Ada).

  > > and (more importantly) runs into copyright 
  > > difficulties: I don't want to infect the Cam3 compiler with the 
  > > GPL. 
Ouch.  That's a problem.


  > >  Where integration would help would be to make sure that the M3
  > > compiler could take full advantage of new gcc features (mainly
  > > optimisation), and avoid bugs in the m3/m3cc interface (ie. bad
  > > optimisation hints).
I also think that moving to egcs will reduce the long term problems with
interfaces inside the compiler changing and because we don't have prototypes
nobody finds out until the compimler mis-compiles something because some
function was missing an argument.

We're certainly not fully prototyped yet, but we are making progress.

  > >  A large amount of maintenance effort actually tends to go into 
  > > either changing compiler functionality or maintaining the libraries.
Libraries certainly require a fair amount of work, and it just gets harder
when you start having to worry about multilibs, cross compiles, etc.  We're
running into these issues with Fortran.

Much of the solution (IMHO) is to move the runtime libraries to their own
toplevel directory (ala libstdc++/libio in the egcs dist).  This really
helps chicken and the egg problems with cross compiles.

jeff