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

What is old is new again

[jockm]

This was a part of NextStep/OpenStep from way back. The application could have multiple binaries. So it would not be common to see a single app bundle that would run on OpenStep 68K, OpenStep x86, and OpenStep for Win32. Even the original Rhapsody was going to be like this supporting Rhapsody PPC, Rhapsody x86, Rhapsody on Win32.

Re:What is old is new again

[_|()|\|]

Maybe Jobs doesn't like his apps being called fat?

OS X 10.4 uses fat binaries. For example, Apple recently botched a security update by failing to ship a fat binary for the BSD layer. This is what it's supposed to look like:

$ file /usr/lib/libSystem.B.dylib
/usr/lib/libSystem.B.dylib: Mach-O fat file with 2 architectures
/usr/lib/libSystem.B.dylib (for architecture ppc): Mach-O dynamically linked shared library ppc
/usr/lib/libSystem.B.dylib (for architecture ppc64): Mach-O 64-bit dynamically linked shared library ppc64

Apple's GCC has built-in support for fat binaries:

$ gcc -o hello hello.m -arch ppc -arch ppc64
$ file hello
hello: Mach-O fat file with 2 architectures
hello (for architecture ppc): Mach-O executable ppc
hello (for architecture ppc64): Mach-O 64-bit executable ppc64

If I had the right SDK installed, I could have added -arch i386. Building fat binaries with GCC and ICC will probably require the use of lipo(1).

Re:WTF?????

[larry bagina]

No, intel is porting their x86 compilers to run under MacOS/intel. The same compilers that already run under windows and linux.

Apple will still be using GCC.

before anyone says it

[ArbitraryConstant]

Before anyone says it, this won't replace GCC on XCode. Intel's compiler is expensive and is not 100% compatible with GCC. It also doesn't support PowerPC so as long as they're supporting both architechtures they can't use ICC exclusively.

It'll be an option for people that need better performance on x86. Any collaboration is so that ICC can be hooked into XCode in an easy to use way.

Short answer? No

[Sycraft-fu]

Longer answer: No, because Intel's tools aren't what people develop with. They make use of Intel's compiler to generate better binaries, but the development is done in Visual Studio (ICC plugs right in).

You still find that by and large Windows apps are developed in Visual Studio because, despite what you may have heard, it's a really, really slick IDE, many programmers claim it's the best ever. Also, since it's from Microsoft, it supports all the Windows stuff (like DirectX) very well.

So the Intel tools peing ported to OS-X make no difference at all. Cross platform will be no easier or harder for it, it'll just mean faster apps on the Mac.

Re:Short answer? No

[mattjb0010]

GCC doesn't vectorize for Altivec

This used to be true, and as you point out this did create a fallacy that all Mac apps are magically faster because the chip has AltiVec. However this changed with the latest version of XCode and gcc 4.0, see here. This also applies to gcc4.0 on x86 with SSEn.

No

[harlows_monkeys]

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?

No. If you write a Mac app using Cocoa, it's only going to run on OS X, regardless of what compiler and other tools you use to build it. If you write a Windows app using the Win32 API, it's only going to run on Windows, regardless of what compiler and other tools you use. Same with Linux.

Conversely, if you write a portable app (or, more realistically, a portable library to use in your non-portable apps), then it will be easy to make it work on different compilers and with different tools on the various platforms, so having the Intel tools everywhere doesn't help that much.

Heck, gcc is widely used now on OS X and Linux, and is readily available for Windows, yet you don't see a great flood of cross-platform development. The Intel tools won't change that.

Re:Foul!

[harlows_monkeys]

Yes, that was to level the playing field... not to show which one was faster... because Apple could have used their own compiler and got faster results too... but the goal was to see which was faster... and then the G5 was indeed faster.

Using gcc on x86 and G5 doesn't in any way whatsoever "level the playing field", since they are NOT the same compiler. The only way to level the playing field is to use the best compiler available for each processor, so that the comparison is indeed comparing the best performance that is available on each.

Cross-platform development started in 1996

[teutonic_leech]

Remember - a little-known language called 'Java'? ;-)

Re:MOD PARENT UP!

[dgatwood]

First of all, since Xcode is free and ICC isn't, it's probably safe to assume that this Xcode enhancement would be available from Intel, not Apple, hence replace gcc, it presumably would not.

Second, I think Xcode just gets its compiler list from reading a series of compiler definition files. As long as you build the definition file correctly, it would just be another compiler you can select from the pop-up list in the target inspector, IIRC. 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'.... :-)

Finally, with respect to the question of it only being useful for people who aren't trying to do PowerPC versions of their software, that's not entirely true. A universal binary is just a couple of ordinary binaries glued together with lipo(1). Build the PowerPC side with gcc (or xlc) and the x86 side with the ICC compiler, glue them together, and you're done. In fact, that's exactly how universal binary builds work when gcc is used by itself....

Re:the promise?

[Anonymous Coward]

Actually, ICC isn't really that much faster than GCC for most software. It only makes a significant difference for code that's inherently vectorizable, can make good use of SSE/SSE2 (and SSE3 if you enable it), and where that code is actually running for a significant portion of the time.

In other words - the math-heavy parts of games, scientific applications, and media encoders / decoders.

For just about everything else, ICC's advantages vanish. ICC basically speeds up the bits that the P4 architecture is already good at, but only on the P4s. On AMD systems, ICC is insignificantly faster.

Don't get me wrong - ICC is a good compiler, which generates extremely good code for a particular architecture. It's just not orders of magnitude better than other compilers.