benedict@chaos.utexas.edu (Thomas Benedict) (03/01/91)
Has anyone gotten BASH or GCC to compile on an RS6000 running AIX? I'm compiling software for a new machine, and have never used an RS6000, so I don't know what kind of tweaking it needs. Tom Benedict benedict@chaos.utexas.edu benedict@utpapa.ph.utexas.edu
bengsig@dk.oracle.com (Bjorn Engsig) (03/04/91)
Article <BENEDICT.91Feb28161639@chaos.utexas.edu> by benedict@chaos.utexas.edu (Thomas Benedict) says: |Has anyone gotten BASH or GCC to compile on an RS6000 running AIX? |I'm compiling software for a new machine, and have never used an |RS6000, so I don't know what kind of tweaking it needs. Did you consicer using Korn Shell (ksh) and its own C compiler xlc? Ksh has the same history mechanism bash has, and xlc is a pretty good ANSI C compiler. If anybody has gcc running, does it produce better code (in any way) than xlc -O? -- Bjorn Engsig, ORACLE Corporation, E-mail: bengsig@oracle.com, bengsig@oracle.nl
john@chook.ua.oz (John Warburton) (03/05/91)
From article <1274@dkunix9.dk.oracle.com>, by bengsig@dk.oracle.com (Bjorn Engsig): > Article <BENEDICT.91Feb28161639@chaos.utexas.edu> by benedict@chaos.utexas.edu (Thomas Benedict) says: > |Has anyone gotten BASH or GCC to compile on an RS6000 running AIX? > |I'm compiling software for a new machine, and have never used an > |RS6000, so I don't know what kind of tweaking it needs. > Did you consicer using Korn Shell (ksh) and its own C compiler xlc? Ksh has > the same history mechanism bash has, and xlc is a pretty good ANSI C compiler. I would think that if people wanted a good shell across a number of different environments, then BASH would be the answer. Also there are a few more options to BASH than ksh can poke a stick at! > If anybody has gcc running, does it produce better code (in any way) than > xlc -O? Well that is rather amusing in its own right. We have been told (in Australia) that the optimiser for the compiler does not work (hence the OS is not optimised code), so the beauty of gcc is made even better as it would most probably be the only optimising compiler for the RS6000. > -- > Bjorn Engsig, ORACLE Corporation, E-mail: bengsig@oracle.com, bengsig@oracle.nl John Warburton [these opinions are my own and are in no way connected with the Dept of computer science, Adelaide Uni.] John Warburton Phone : +61 8 228 5583 Department of Computer Science Telex : UNIVAD AA89141 University of Adelaide Fax : +61 8 223 1206 GPO Box 498 Adelaide SA 5001 ACSnet : john@cs.ua.oz
marc@stingray.austin.ibm.com (Marc J. Stephenson/140000;1C-22) (03/05/91)
In article <2547@sirius.ucs.adelaide.edu.au> john@chook.ua.oz (John Warburton) writes: >From article <1274@dkunix9.dk.oracle.com>, by bengsig@dk.oracle.com (Bjorn Engsig): > >> If anybody has gcc running, does it produce better code (in any way) than >> xlc -O? > >Well that is rather amusing in its own right. We have been told (in Australia) >that the optimiser for the compiler does not work (hence the OS is not optimised >code), so the beauty of gcc is made even better as it would most probably >be the only optimising compiler for the RS6000. > This is blatant misinformation. With few exceptions, the operating system, commands, libraries, and LPPs are compiled optimized. Looking right at the output from a build, the only things that I could find in the base which were not compiled optimized were diagnostic test units, which could easily be affected by timing. There may have been some time during development of AIX 3.1 where it was necessary to build the system unoptimized, but I could not verify that. This has certainly not been the case for any version of AIX 3.1 which has been available to the general public. What you have been told (in Australia) is incorrect. -- Marc Stephenson IBM PSPA (Personal System Programming - Austin,TX) DISCLAIMER: The content of this posting is independent of official IBM position. marc@stingray.austin.ibm.com VNET: MARC at AUSVMQ IBM T/L: 793-3796
bengsig@dk.oracle.com (Bjorn Engsig) (03/05/91)
In article <1274@dkunix9.dk.oracle.com> I wrote: | If anybody has gcc running, does it produce better code (in any way) than | xlc -O? And in article <2547@sirius.ucs.adelaide.edu.au> john@chook.ua.oz (John Warburton) wrote: | |Well that is rather amusing in its own right. We have been told (in Australia) |that the optimiser for the compiler does not work (hence the OS is not optimised |code), so the beauty of gcc is made even better as it would most probably |be the only optimising compiler for the RS6000. That ceased to be true around summer (Northern Hemisphere) last year. Today, the C compiler and optimizer has very few bugs left. We found a few ourselves that have been fixed by now (3003 update). Personally, I believe that gcc will never beat xlc, but having some results will of course be very wellcome. -- Bjorn Engsig, ORACLE Corporation, E-mail: bengsig@oracle.com, bengsig@oracle.nl
hbergh@oracle.nl (Herbert van den Bergh) (03/06/91)
In article <2547@sirius.ucs.adelaide.edu.au> john@chook.ua.oz (John Warburton) writes: |I would think that if people wanted a good shell across a number of different |environments, then BASH would be the answer. Also there are a few more options |to BASH than ksh can poke a stick at! What options are you talking about? Besides, I think it is preferable to have a good shell which is supported by many vendors on many systems than to have to port a public domain program to all platforms you use. If you work only on one platform, and that one doesn't have ksh, start flaming your vendor now. |> If anybody has gcc running, does it produce better code (in any way) than |> xlc -O? | |Well that is rather amusing in its own right. We have been told (in Australia) |that the optimiser for the compiler does not work (hence the OS is not optimised |code), so the beauty of gcc is made even better as it would most probably |be the only optimising compiler for the RS6000. That's nonsense and you should know it, because it's easy to verify that the optimizer DOES work. There may have been some bugs in the XLC optimizer, but they will get fixed sooner or later. I wonder if GCC will ever optimize as smart as the XLC compiler does. Try for example to compile one of your programs with -qlist, with and without -O, and look at the difference in size, speed and generated code. Pretty amazing stuff. -- Herbert van den Bergh, Email: hbergh@oracle.nl, hbergh@oracle.com ORACLE Europe --
karish@mindcraft.com (Chuck Karish) (03/07/91)
In article <5737@awdprime.UUCP> marc@stingray.austin.ibm.com (Marc J. Stephenson/140000;1C-22) writes: >There may have been some time during development of AIX 3.1 where it was >necessary to build the system unoptimized, but I could not verify that. >This has certainly not been the case for any version of AIX 3.1 which has >been available to the general public. The reports we read in this forum last year said that the first fully optimized AIX 3.1 was pre-release build 9019 from last May, about a month before GA. The presentations I've seen and articles I've read on the S/6000 suggest that gcc will never be really efficient on these systems unless someone creates a back end and an optimizer for it that really understand the architecture. My feeling is that gcc's place in the world is not as the be-all and end-all of C compilers, but as a relatively bug-free reference implementation that people can use as a sanity check for other compilers (and for a stop-gap when the others fail). Chuck Karish karish@mindcraft.com Mindcraft, Inc. (415) 323-9000
jeffs@soul.esd.sgi.com (Jeff Smith) (03/07/91)
|> Well that is rather amusing in its own right. We have been told (in Australia) |> that the optimiser for the compiler does not work (hence the OS is not optimised |> code), so the beauty of gcc is made even better as it would most probably |> be the only optimising compiler for the RS6000. I doubt this. The RS/6000 architecture replies heavily on optimizing compilers to keep it's multiple instruction units pipelining well. I'm also pretty sure most of the OS is build -O (although I haven't worked on AIX v3.1 since before GA). The IBM compiler does do all the major optimizations, and some very fancy stuff for instruction scheduling. The major problem with the IBM compilers is that some of these techniques take alot of RAM, and the compiler process can get quite large. Hopefully this will get cleaned up over a few releases. I think it will be some time before gcc can produce code as good as the IBM compiler since the instruction scheduling is pretty complex (as compared to other RISC architectures). jeffs@sgi.com "just another ex-compiler guy" "Look Mom, I didn't even slam AIX"
kstailey@geech.ai.mit.edu (Kenneth Stailey) (03/10/91)
According to the new pink GnusBulletin GCC 2.0 will support the
RS/6000. Even though it does not optimize well for RISC gcc will be
nice because it doesn't eat up all the swap space on the machine, it
produces normal-looking error messages (ones that Emacs can step
through), it has the same behaviour on multiple machines which makes
porting easier and the source code is available at little or no cost.
Bash should be an 'easy port' (i.e. 29 head throbbing hours at the
compiler) but I haven't tried and ksh myself. I ported Emacs by
myself partly for practice and partly just to have it. The only
problem with my port is that when you resize the X-window it adds a
blank row and column to the bottom and right of the window. Any
'buggestions' as to why will be greatly appreciated.
@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@
Disclaimer: This message is sold by weight not volume; |
contents may have settled during shipment. @
@ replys to kstailey@churchy.ai.mit.edu or kstailey@leidecker.gsfc.nasa.gov
| NBCS: B4 f m w- c(+) p+ k+ s+ please don't ask me what NBCS is.
@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@
--
@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@
Disclaimer: This message is sold by weight not volume; |
contents may have settled during shipment. @
@ replys to kstailey@churchy.ai.mit.edu or kstailey@leidecker.gsfc.nasa.gov
| NBCS: B4 f m w- c(+) p+ k+ s+ why jack off when you can jack in?
@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@hubler@galaxy.lerc.nasa.gov (Dale Hubler) (03/11/91)
In article <KSTAILEY.91Mar9142417@geech.ai.mit.edu> kstailey@geech.ai.mit.edu (Kenneth Stailey) writes: >According to the new pink GnusBulletin GCC 2.0 will support the >RS/6000. Even though it does not optimize well for RISC gcc will be >nice because it doesn't eat up all the swap space on the machine, it >produces normal-looking error messages (ones that Emacs can step >through), it has the same behaviour on multiple machines which makes >porting easier and the source code is available at little or no cost. One other benefit of having GCC ported is that G++ cannot be built without GCC. Is anybody at FSF working on G++ availability for the RS6000? -- Dale A. Hubler -- Sverdrup Technology -- (216) 977-7014 hubler@galaxy.lerc.nasa.gov "There is no room in democracy for intolerant people, Therefore they should all be rounded up, taken out back, and shot"
jfc@athena.mit.edu (John F Carr) (03/11/91)
In article <1991Mar10.164350.25082@eagle.lerc.nasa.gov> hubler@galaxy.UUCP (Dale Hubler) writes: >Is anybody at FSF working on G++ availability for the >RS6000? gcc version 2 includes g++; porting gcc has a side effect of porting g++. -- John Carr (jfc@athena.mit.edu)