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?"
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?
the present of cross plataform is already here, it's called GCC.
Wow, who'd have expected something like this?
If you forget about the future, the future will forget about you.
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.
So it doesn't compile ObjC-Cocoa apps.... And Apple is abandoning the Classic environment available on the x86 platform...
And there's no IOKit....
So what's this going to compile? Core Foundation apps and Carbon apps without any vector code?
Ummmm. Well, it's a start.
Yes it's crossplatform alright if the compiler in question works for x86, x86 and you guessed it: x86.
What's making the porting hard in case of different software ecologies is not the compiler, cause gcc is really crossplatform and ubiquitous for years now. It's all those OS and otherwise libraries (gtk vs. cocoa vs. GDI) which do it. And I don't see Intel selling any crossplatform versions of those
Yes, if you define "cross platform" as being restricted to Windows, Mac and Linux. Also, this does not include PPC, which is another platform that Mac runs on. I am not optimistic that this is any sort of harbinger of great things, but it will be very nice to have three platforms that share the *same* hardware architecture, roughtly speaking.
Currently hooked on AMP
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.
Is Intel trying to make us forget about all those IBM-powered XBox 360, PS3, and Revolution systems to come?
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
Because all mainstream personal computers will use the same x86 processor in the next two years, certain programmers who deal with assembly issues will be relieved. However, we still have Carbon/Cocoa, Win32, and GTK/QT/POSIX to deal with.
And we currently have cross-platform tools. It's called the GNU toolkit (autoconf, gcc, gdb, gmake, and a few other handy applications that are used on just about every platform availiable).
Apple is switching from gcc to intel's compiler? What the hell is going on here, all of a sudden apple is becomeing less OSS friendly...
... ICC only runs on x86. OS X had its native "made by processor designers' home company(tm)" compiler when it was (and still is) on PowerPC, now that Apple's going to Intel, it just seems logical that Intel does this. At least to show a little support to Apple.
:)
IBM compilers (xl* compilers) were proprietary software and still were ported to OS X too, and AFAIK had better performances than gcc on PPC970 (even though Apple did help on optimizing gcc on G4/G5), just like ICC is better than gcc on x86 for most purposes (check benchmarks for yourselves).
No I'm not an Apple fanboy (please! I don't have any Apples nor plan to buy any) and I don't care much about Intel either. I'm more a free software guy trying to run only free software as far as I can for different reasons... And still I don't see how Apple could be less OSS friendly just because some other company (may it be Intel or not) releases closed softwares.
Where does it say Apple will stop using gcc themselves (and distributing it with OSX)? gcc runs on plenty of hardware and os'es
However, I'm not saying Apple is supporting "open source" software. I'd say that they're using FOSS smartly for now, but I don't see them in the OSS camp.
Lastly, ICC having better results than gcc gives the gcc team a great challenge and gcc4 is already a big improvement. ICC on OSX gives more choices to OSX developpers who would need good optimization for intensive arithmetic operations (where ICC shines). Anyway, gcc has strictly nothing to fear from icc, they're aimed at totally different "markets", and gcc is free, so what's to fear?
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.
>"When Apple tried to "prove" that the G5 was "better" than the Intel, it purposely didn't use the Intel tools, but used the GNU tools instead."
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.
>"Their desire to use the Intel tools now demonstrates that they didn't use the Intel tools in their G5/Intel benchmarks because they knew Intel tools outperform GNU for Intel."
You're right but then, they never said otherwise. You, like so many others equated the use of GNU rather than Intels compiler as a means of skewing the results when it was about creating a level playing field.
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.
Can someone please shead some light over the AltiVec part ocf the article?
Why would Intel even consider supporting AltiVec in a compiler for x86? This just sounds bizarr, considering altivec only exists in the PPC world...
Maby they really mean compiler-level conversion of AltiVec calls to SSE calls?
When in doubt, act determined. Business 101
Remember - a little-known language called 'Java'? ;-)
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.
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.
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.
Please RTFA, noone said they would use ICC on PPC, its just stating that ICC will be able to produce binaries for OSX. Heck, if this article didnt exist, I would be upset. Damned if I would use GCC over ICC, ESPECIALLY, if I was positive the only chip the binary would be used on is an Intel chip. ICC may not be the best for Windows Development seeing as the large numbers of AMD processors are abound, but this makes perfect sense for OSX.
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.
Donate free food here