Slashdot Mirror
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?"
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.
What do you know I wrote a novel
Apple will still be using GCC.
Do you even lift?
These aren't the 'roids you're looking for.
Sixth paragraph from the bottom.
Intel's Mac OS X tools are still in the early stages of development, and Intel has not completed fingering CmdrTaco's asshole yet.
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.
I rarely criticize things I don't care about.
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.
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.
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.
It hasn't been long since I was reading (here on Slashdot, if I recall right) about how Intel sabotaged their own compilers to make their output run badly on AMD processors.
Add to that, we are going to be supporting both PPC and X86 on the Mac for many years to come.
Does Intel's compiler even have solid Objective-C support?
Unless I hear something new to change my mind, I have to presume that very few developers will show any interest in Intel's compiler. They'll almost all stick with GCC -- which is what I plan on doing, certainly.
Remember - a little-known language called 'Java'? ;-)
And the Windows binary would be in PE (Portable Executable) format (we're presuming Win32 or Win64 here), the Microsoft executable file/dynamically-loaded code file format, while the Linux binary would be in ELF (Executable and Linking Format), the executable file/dynamically-loaded code file/object file/core dump file format, originally developed by AT&T, used on Linux, most BSDs, Solaris, and at least some other UN*Xes these days.
The program would probably compile on most if not all other UN*Xes, including OS X, and be in the native binary file formats for those OSes (ELF, as per the above, on many other UN*Xes; Mach-O in OS X; various mutant flavors of COFF (Common Object File Format, also developed by AT&T, and mutated by various UN*X vendors into ECOFF, XCOFF, etc.) on some other UN*Xes.
ELF binaries for one OS might, or might not, work on another OS. Binaries for Windows would only work on UN*Xes with the aid of software to run Windows binaries, such as Wine; binaries for various UN*Xes probably wouldn't work on Windows at all (I know of, for example, no "inverse Wine" to let you, for example, run Linux binaries on Windows). Binaries in one format might, or might not, work on an OS using a differenrt format.
User-mode code generated for x86 (and EM64T, if Intel's tools support it) should work on AMD processors (I think for user-mode code EM64T is just x86-64), although you probably won't be able to optimize for particular AMD processors.
However, the answer "No" is still correct, as a lot of "cross-platform development" between Windows, OS X, and UN*X+X11 (of which many Linux distributions are instances) can involve supporting different GUI toolkit APIs on those platforms, so this isn't "the future of cross-platform development" unless Intel provides tools to make the same app run on different toolkits.
Combining it with, for example, Qt (or GTK+, if you're willing to live with an X11-based app on the Mac) might provide a platform for cross-platform development of GUI apps.
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....
Check out my sci-fi/humor trilogy at PatriotsBooks.
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.
Actually, that's not quite the case. There are many situations where you have plain C libraries that are used by Obj-C apps, and you can build those libraries with the Intel compiler. Also, the Intel compiler should work just fine for Carbon apps.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."