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: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.

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.

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.