rps@arbortext.UUCP (Ralph Seguin) (06/04/91)
Hi. Are GNU CC and G++ available for the RS/6000? Where? What contortions are necessary to get it to work. Thanks, Ralph
rbraun@spdcc.COM (Rich Braun) (06/07/91)
This is an FAQ, and alas the answer is No so far. However, I've heard that "certain university hackers have brought up gcc on the RS/6000" on their own. 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, which is obviously months or years in the future (this is due to a spat between IBM and the FSF; IBM is worried about "contaminating" its code with copylefted sources, so it refused to make some FSF software available to its customers--that's how I remember the episode). Will any of the aforementioned university hackers step forward and let us know of the availability of any unsupported gcc derivatives for the RS/6000? There's a deep well of demand for it. -rich
jtw@lcs.mit.edu (John Wroclawski) (06/07/91)
In article <7749@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes:
From: rbraun@spdcc.COM (Rich Braun)
Date: 6 Jun 91 17:49:47 GMT
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, which is obviously months or years in the future (this is due to a
spat between IBM and the FSF; IBM is worried about "contaminating" its
code with copylefted sources, so it refused to make some FSF software
available to its customers--that's how I remember the episode).
Say what? 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.
Once long ago IBM decided to not ship gnu emacs with a product after
saying they would because the folks who sell another emacs claimed, in
the interim, that gnu emacs used some of their code. In fact, Stallman
appears to have had permission from the original author of that code
to use it; in any event the code in question since been completely
rewritten. None of this past history has anything to do with gcc.madd@world.std.com (jim frost) (06/08/91)
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
oasis@gary.watson.ibm.com (GA.Hoffman) (06/12/91)
floating-point | fixed-point scheduling is certainly important .. perhaps even more so is scheduling ops that materialize condition codes and conditional branches that use them. oh .. don't forget loads... loads are very important also. these items are for fixed- point performance as well as floating. -- gary a hoffman RISC Systems, Watson Research