Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!world!madd
From: madd@world.std.com (jim frost)
Newsgroups: comp.unix.aix
Subject: Re: GNU C,G++ for RS/6000
Message-ID: <1991Jun8.064102.9340@world.std.com>
Date: 8 Jun 91 06:41:02 GMT
References: <389@arbortext.UUCP> <7749@spdcc.SPDCC.COM> <JTW.91Jun6151339@mercury.lcs.mit.edu>
Distribution: na
Organization: The World @ Software Tool & Die
Lines: 33

jtw@lcs.mit.edu (John Wroclawski) writes:

>In article <7749@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes:
>   From: rbraun@spdcc.COM (Rich Braun)
>   The Free Software Foundation has stated in no uncertain
>   terms that the RS/6000 won't be supported until gcc version 2.0 comes
>   out

>I'd imagine the primary reasons for not supporting the
>RS/6000 in gcc 1.x are a) gcc1 doesn't have the ability to do
>instruction scheduling for superscalar processors well, while gcc2
>does, and b) gcc2 is close enough that it doesn't make a whole lot of
>sense to put effort into a gcc1 port, specially given that gcc2 will
>be able to generate much better code for this particular machine.

Actually the chip isn't superscalar enough to have much effect on code
generated by most compilers.  About the only scheduling you can do is
interleaving fp and int instructions and moving cmp instructions
backward away from branch instructions to get "free" branching.  Xlc,
IBM's compiler, doesn't seem to try too hard to schedule instructions
but rather spends its time with more commonplace (and effective)
optimizations.  Given the job that gcc does with thge same kinds of
optimizations I imagine that even gcc1 would do a pretty good job.

Personally I think the big deterrent is trying to generate code that
is compatible with AIX's interesting linking mechanisms.  The function
descriptor idea, introduced with the original RT, is used heavily on
the '6000.  It's a nightmare when porting standard compilers, most of
which assume that address of function == address of function text.

Happy hacking,

jim