IBM releases compiler for G5

I'm sure Apple will use it if they don't already. Why would they not? They could solve some of the speed issues just by recompiling.
 
Originally posted by arden
I'm sure Apple will use it if they don't already. Why would they not? They could solve some of the speed issues just by recompiling.
Click to expand...

They aren't using IBM's compiler now, and I doubt they would jump over to IBM's compiler later just because it is more optimized for the G5. On top of that, we don't know how optimized IBM's compiler is over gcc (considering Apple and IBM optimized that for the G5 to an extent already).

G5s don't have speed issues with OS X to begin with, and using IBM's compiler will not improve any speed issues you have with your G4/G3 system now.
 
Yes, what speed issues? ;-) Plus: It's a C++ and Fortran compiler, so it doesn't compile Objective-C (so far). Also: Apple would quite surely not switch compilers for Panther NOW so shortly before release time (let's hope it's AppleExpo Paris!). Also, it's a compiler only for the G5 processors. Do we want to be second class citizens on G3s/G4s so fast? No, we don't.

It's always a pro/con-thing with backwards compatibility, but with iBooks shipping with G3 processors, PowerBooks/iMacs/eMacs shipping with G4 processors, this is quite certainly a no-go.
 
The News out of NASA is that it compiles for the G4 quite nicely and that is significanty faster.

The thing to keep in mind about GCC is that it is above all else a portable compiler and it uses a generic model of what a processor is and can do. As soon as you can specialize on a single archetectrue or processor there are many more things the compiler can do.
 
Actually if you read the thread (and the associated Ars thread) you will see that the compiler does indeed compile code for any altivec enabled PowerPC chip including the G4. This compiler does not compile objectiveC but it could be used to compile low level core system libraries... Either way, its a nice development :)
 
I wonder if we'll see benchmarks with this new compiler soon.

All the wintel goons starting crying when the benchmarks didn't use Intel's optimised compiler. I wonder how the IBM compiler on a G5 would compare with the Intel one on a P4.
 
If it produces faster code than GCC 3.1(shouldn't be that hard :D) for the G4 as well as the G5, then why SHOULDN'T Apple use it?

I doubt they would switch compilers for Panther this close to release, but it could be possible.

They'll need to update it with Objective-C support before using it in XCode, or they could have it the default compiler for C/C++ and GCC 3.1 for Objective-C.
 
I think they're using GCC 3.3 with XCode and Panther. That's supposed to be much better than its predecessor.

Doug
 
Yeah, I think so too. I'm pretty sure they mentioned it in the WWDC keynote.
 
Ugh, the only problem with switching over compilers is that you cannot compile the OS with xlc, and then compile IOKit drivers with gcc 3.3. (IOKit uses C++, and nearly every compiler compiles C++ linkages differently)

To be honest, I wouldn't be too worried about pushing xlc... 3.3 did get some hints as to how to compile G5 code that 3.1 doesn't have (and 3.3 is just better in general in terms of optimization). Plus, if you look on the PC side, quite a few use VC++ which is one of the worst when it comes to optimizing.

While it would be nice to see xlc come in, it would break drivers and require a recompile of drivers (for the 3rd/4th time)... and would NEED Obj-C support before Apple takes it... even then Apple might not use it since it cannot create x86 or usable G3 code. Apple does test the OS by compiling it onto x86 and make sure hidden bugs don't crop up.
 
Originally posted by Krevinek
Ugh, the only problem with switching over compilers is that you cannot compile the OS with xlc, and then compile IOKit drivers with gcc 3.3. (IOKit uses C++, and nearly every compiler compiles C++ linkages differently)
Click to expand...

Just a note on this I believe that the C++ ABI for both compilers is supposed to be the same so you could mix and match objects compiled with one and the other. The problem is that I think the C++ ABI used by IOKit is itself a little bit different. It is not really true that it uses C++ but rather a subset of C++ which has been blessed as "OK" for use in the kernel. So xlc would need to also support the "IOKit ABI" for one to use it to compile the kernel stuff.

-Eric
 
I wish I understood what you were talking about... fortunately, after some time with my Computer Science class, I will.
 
The ABI is the Application Binary Interface which is basically the programming interface at the assembly level. It includes things like how are arguments put onto the stack and how do you make a system call. In the case of C++ it includes how classes are represented in memory and how method dispatch works. The reason that you generally cannot mix and match C++ code is that different compilers use different ABIs. Now if they use the same ABI, which I believe xlc and G++ do, you are able to mix and match at will since the compiled binary code is compatible.

Hope that helps!
-Eric
 
OK, yeah, I know what you are talking about now. :) I just didn't know that was called the ABI.
Thanks
 
You must log in or register to reply here.
Back
Top