Re: Gnat Free ?

[Jonathan Guthrie <jguthrie@weck.brokersys.com>]

Finally!  While I appreciate all the people who have made suggestions directed
toward helping me get a copy of this working, what I REALLY want to talk about
is the consequences of basing your compiler on someone else's compiler that is
being actively developed.  For those of you who have made suggestions, I have
already tried some of them, I may try others, later.

Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> On 18 Oct 1998, Jonathan Guthrie wrote:
>> dewarr@my-dejanews.com wrote:
>> > We are perfectly aware that there are enthusiasts who would like to get their
>> > hands on the latest technology, and don't care if it has problems. But that is
>> > not the public we are addressing in making public versions of GNAT available.

>> Actually, the biggest pain in the neck with GNAT is the fact that ACT
>> doesn't update the GCC patch files between public releases. 

> This is a legitimate gripe. However, in your case, as someone who is
> "just" using GNAT to learn (no disrespect intended!) the solution is to
> install a standalone version of GNAT which doesn't interfere with the GCC
> you are using to do real work. Disk space is cheap, no?

"Standalone version"?  You speak a strange dialect, sir.  What do you mean?
It's been too many months for me to remember why replacing gnatmake (gnatbuild?
that's gone with the mists of time, too) with a version that calls gnatgcc
instead of gcc (the fix I applied to get g77 and gnat to coexist) didn't work
in this case.  Is that similar to what you're talking about?

>> While I don't think there's anything wrong with only making a release of
>> the free compiler every once in a while, (I so rarely update compilers
>> without being forced to that I'd never notice,) I think that when you base
>> your compiler on somebody else's, you should accept the burden of making
>> sure that the available free release of your compiler works with any new
>> releases of the base compiler soon after the release of the new version of
>> that compiler.

> I roughly agree, with the caveat that I'd qualify the last sentence to
> only include stable new releases of the base compiler, since there have
> been quick fixes after new GCC releases, and I'd rather ACT be focused on 
> improving GNAT rather than tracking each miniscule patch to GCC. 

When make the choice to use the Gnu C back end, you gain tremendous
advantages.  There is no need to write a code generator or to port that
code generator to new platforms.  Since Gnu C is already popular and has
been ported to a wide variety of platforms, you get easy (well, easier)
porting to those platforms and since there are numbers of people improving
parts of the compiler, including the optimizations and code generation,
you have a realistic hope of getting good code out of that back end.

However, those benefits have a price.  The Gnu C people can easily screw you
up, even if only by accident.  To avoid that, there needs to be coordination
between the you and the Gnu C maintainers.  I would expect that this
coordination, which I have reason to believe IS going on in the case of GNAT,
would result in two phenomena:  First, the number and significance of patches
to be made to the existing Gnu C back end should decrease with time as they
are integrated into the base Gnu C source set.  Second, the number of large
changes to the function calls that constitute the front end/back end interface
should also decrease with time.

The consequences of the decreasing number of patches to the back end are, I
hope, self-evident.  The lack of changes to the calling conventions should mean
that the front end source does not have to be patched in the event of any likely
back end changes.

That means that, ideally, there is NO effort to "port" GNAT to a new version
of Gnu C.  Until ACT reaches that ideal, some kind of judgment has to be made
about how much effort goes in to keeping the distributed source for the front
end up with the changes someone else keeps making to the back end.  I agree
that it probably isn't worthwhile to make a patch file for every release, that
it probably isn't worthwhile to update the GNAT source at all between GNAT
releases because of changes to Gnu C, and that the changes to the Gnu C patch
file would necessarily be released some time after the version of Gnu C which
they patch, but Gnu C V2.8.1 has been out for seven months and (to my
knowledge---I quit looking in May) no patch file for has been made for it.

-- 
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.