Intel Ports Developer Tools to Mac OS X

turnitover writes "According to eWEEK, "Intel Corp. will port its software developer tools to Mac OS X and will ship its first beta later this year, the chip maker told developers on Tuesday at its first-ever session on Mac OS X at the Intel Developer Forum in San Francisco." This, as Apple is working on its first Intel-based Macs, due sometime in 2006. Will the promise of the same feature set and the same tools (for Windows, Mac and Linux) mean the future of cross-platform development is here?"

Comments

A Big Deal

[Nom du Keyboard]

Intel sure keeps making a big deal of this Apple deal. Considering that 90%+ of their processors will still go into Windows-based systems that won't run OS-X (not, at least, if Apple can prevent it), and the first Apple+Intel systems are still a year away if not more, there sure seems to be a lot of Intel/Apple news press releases.

Is Intel trying to make us forget about all those IBM-powered XBox 360, PS3, and Revolution systems to come?

Re:the promise?

[ZG-Rules]

I'm not knocking GCC, it's great - but ICC creates the fastest code for Intel processors and probably the fastest code for AMD processors too. I expect a barrage of flames for saying this, but there's loads of evidence out there for it.

Imagine an x86 Mac and a PPC64 Mac (G5) of equivalent specs, running OSX of the right flavour, both compiled with GCC. You'd expect them to both perform the same right? Now take your x86 OSX and recompile it with ICC and you get an immediate speed improvement... wouldn't you?

Just because Apple support GCC (and will continue doing so unless ICC for OSX suddenly becomes free or they start charging for XCode) doesn't mean they shouldn't compile their entire O/S with ICC to take advantage of the speed.

Re:Short answer? No

[Slack3r78]

However, what it does mean is that ICC will also plug into X-Code, meaning binaries for Mactel machines will be *fast*. While I don't care for many of Intel's products, their compilers are superb (so long as you're using an Intel chip).

One of the great farces of the PPC Macs, in my mind, was the weight Mac users put into Altivec. Yes, it's a solid vector process, but, as I understand it, GCC doesn't vectorize for Altivec -- meaning, quite simply, that Altivec optimizations had to be done by hand. On the other hand, ICC is generally lauded for its ability to vectorize code in a manner that lends to performance increases thanks to the SSE/2/3 vector units on Pentium chips.

There've already been a lot of reports that OS X on x86 is faster than on PPC, the availability of Intel compilers for the platform will only make that difference more dramatic.

So PPC machines get left behind

[SiliconTrip]

The article states that this compiler WILL NOT produce ppc binaries.

So does this mean that developers who use this compiler will be producing x86 only binaries and ignoring all the existing Mac PPC hardware?

--
Not happy Jan.

Re:AltiVec ona a x86 compiler?

[Matthias Wiesmann]

The trick is that nobody programs in Altivec assembly. Altivec programming was done using intrinsic C functions that would map directly on the right Altivec instruction. Usually the c-functions had the same name as the opcodes. There is a special keyword "vector" to identify vector data.

If intel's compiler supports in some way those intrinsic functions (A large part might be doable as macros) and maps them to the relevant SSE instructions then Altivec optimized programs would a) still compile b) use the already vectorized code to generate vector assembly. I is beyond me how easily you can map one vector instruction set on the other. There certainly won't be a 1 to 1 mapping.

Can't wait

[wandazulu]

Just like on the G5, I have some apps that have a cocoa/obj-c front end to a pure 64 bit c++-based set of libraries written using xlC for performance reasons. I'll be happy to do the same thing on an Intel-based mac when it becomes generally available (and assuming that it'll also support 64-bit addressing).

Frankly, I don't see the need for Intel to worry about obj-c much...I would think the gains are not really worth it...if you're doing something graphically intense, then you're presumably going to target the gpu, and if it's mathmatically intense, you'd probably want straight C or C++ with templates.

Hell, if I thought it'd be even faster (and I knew how to program in it), I'd write my libraries in Fortran.

Re:MOD PARENT UP!

[Halo1]

Xcode has supported gcc 2.95/3.0/3.3/4.0 for a while now, so this really isn't anything different from that perspective beyond its name not starting with 'g'.... :-)

Unfortunately, that's not true. Several people have already tried to add support for other compilers to Xcode and apart from using script build phases, there doesn't seem to be a solution currently. If you start editing Xcode's gcc description files to change them for working with another compiler (i.e., to expose the command line options via the GUI), you only get Xcode crashes.

Of course, Apple could modify Xcode and add support for ICC, but it's not just a matter of editing some file... Integration in Xcode of compilers other than what Apple supports out-of-the-box is currently a nightmare.

Re:the promise?

[TheRaven64]

Objective-C is really just a thin wrapper around C. All of the runtimes methods are exposed as C functions (take a look in /usr/include/objc/ - you can do some quite shiny things calling the runtime methods from your code). In early implementations, a very simple pre-processor translated Objective-C into C and then compiled the C. It is possible that Apple could return to this route - I don't know how much optimisation is done at the Objective-C level that is not done at the C level, but I suspect it is not a huge amount.