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

[Michael Neuffer <neuffer at goofy dot zdv dot uni-mainz dot de>]

On Sun, 28 Dec 1997, Richard Watts wrote:
> >> > Does anyone know if there is anybody still working on
> >> > SRC-Modula3 ? 
> >> 
> >> Yes, there is still development going on.  The folks at SRC aren't
> >> doing too much on it any more, but other developers have picked it
> >> up.  There's even a commercial version -- see <http://www.cmass.com>.
> >
> >There is a non-commercial branch from SRC-M3 which seems to be much more
> >active: Cambridge Modula-3
> >
> >http://www.cl.cam.ac.uk/m3doc/linux/cambridge.html
> 
>  :-). You might also want to have a look at polymtl M3 - Cam3 and pm3 
> tend to get things added to them as and when the maintainers have effort
> available, but pm3 tend to have more effort available. 

Where can I find it ?

> There are plans 
> afoot to merge the distributions just as soon as we can figure out 
> how :-).

:-)

> >Richard Watts <Richard.Watts@cl.cam.ac.uk> is working on getting 
> >CAM3 to work with glibc 2. The same patches would probably then also fit
> >for SRC-M3 
> 
>  Apart from some problems with m3gdb, reported by  Rajat Datta 
> <rajat@ix.netcom.com> and the fact that I forgot to add a declaration for
> getcwd :
> 
> <*EXTERNAL*> PROCEDURE getcwd (pathname: char_star; count : int): char_star;
> 
>  (also thanks to rajat@ix.netcom.com, who spotted that), you can pick
> up some (very basic: I didn't have time to package them properly) patches 
> for glibc2 support for Cam3 from
> 
> ftp://epona.ucam.org/pub/users/rrw/Cam3-LINUXLIBC6.tgz 
> 
>  I'm still having problems with X binaries, but I suspect that's
> just a problem with my setup (Rajat didn't seem to have any problems with
> RH 5).

John, do you think this might be enough to get CVSup running ?

>  I'll get around to packaging the glibc2 patches up properly when I 
> get back to college - probably around the 6th or 7th: the interactive
> performance of this 'net link is awful (mutter mutter the good old days
> mutter mutter 2400 baud mutter mutter bloody web traffic mutter :-()

I can understand your feelings. I often see >40% package drops on
connections within Germany. 

> >> 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..
> 
> >
> >> I updated it fairly painlessly to the 2.7.2.1 code generator,
> >> and that's the version used under FreeBSD.  The Modula-3 specific
> >> files for the 2.7.2.1 code generator can be found at:
> >> 
> >> ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/LOCAL_PORTS/m3-fbsd-m3cc-3.6.tar.gz
> >
> >Did anyone ever think about integrating M3 with gcc/egcs as an additional
> >frontend similar to the Fortran and Pascal frontends ?
> 
>  Yes. It would be nice, but it would also probably be a lot of work,
> probably wouldn't be supported (I presume the frontends need to be
> written in C/have the same general invocation requirements/whatever
> to be supported ?), and (more importantly) runs into copyright 
> difficulties: I don't want to infect the Cam3 compiler with the 
> GPL. 

What copyright is it under at the moment ?

>  What are the current maintenance arrangements for the multiple
> frontends ?

I´m not sure. 

Maybe some of the Pascal or Fortran developers could comment on that ?
The Fortran and Pascal are definitely under GNU copyright.

> >I think that would make more sense in the long run then duplicating or
> >even triplicating porting efforts of different (semi-)independent 
> >branches.
> 
>  Well, yes and no: porting efforts are mostly in the realm of getting
> the C API right (the glibc2 port, for example, is just a set of 
> replacements for the Unix and C interfaces which need to be equivalent
> to the C header files), so it'd have to be done anyway, and as John
> Polstra says, these are pretty much uniform over all branches, so
> porting only has to be done once anyway (SRC and polymtl can more or
> less copy Cam3, and vice versa).
> 
>  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).
> 
>  A large amount of maintenance effort actually tends to go into 
> either changing compiler functionality or maintaining the libraries.

I see. 


Mike