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?"
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.
Kevin Smith, director of Intel Compiler Labs, said that Intel will port a complete set of compilers and performance-enhancing libraries to Apple Computer Inc.'s Intel-based version of Mac OS X. Intel will provide Mac tools for both single-core and multicore processors based on Intel's latest compiler technology. Smith said that the tools will contain the same feature set that Intel now provides for its Windows and Linux development tools.
"We will offer one set of tools for all OSes," said Smith.
Intel's compilers and libraries will work as plug-ins to Apple's Xcode development environment running in Mac OS X for Intel. Smith said Intel has no plans to offer the Mac tools in a version running on its Windows development environment. Developers creating software for both operating systems must use the tools running on each platform. The Mac OS X compilers and libraries will require Apple's prototype Intel-based Macs hardware and won't run on generic PCs, he said.
eWEEK.com Special Report: Intel Developer ForumIntel will help developers migrate from PowerPC to Intel architecture, according to Smith. Intel won't, however, provide tools for the simultaneous creation of software for both Intel and PowerPC processors, a strategy that Apple has said will help the transition to the Intel architecture.
The Intel tools will support C, C++ and FORTRAN, but will not provide a compiler for Objective C, a language that Apple supports for Mac OS X developers. The Intel tools will be interoperable with Objective C. Smith said that Intel will also provide a migration guide for Metrowerks, a programming environment that Apple will not support with Mac OS X for Intel-based Macs.
Intel's Mac OS X tools are still in the early stages of development, and Intel has not completed fingering CmdrTaco's asshole yet.
"We're not at the demo stage yet," said Smith.
eWEEK.com Special Report: Apple's Switch to IntelIntel will support the development of device drivers for Mac OS X but has not made any decisions on what that support will take. Smith said that the first release will not have integration with I/0 Kit, Apple's device driver subsystem. I/0 Kit also enables high-level applications to access the hardware.
Intel has also not considered whether it will support Altivec instructions, a 128-bit vector execution unit in PowerPC G4 and G5 processors. Such support won't be in the early betas.
Intel's emphasis on performance is the reason why developers should use Intel's compilers and libraries, according to Smith.
"We'll do more tuning for Intel Macs than anyone else," he said.
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...
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
Ah yes, I remember the first night that I and my loved, Deloris, practiced anal love. She was sitting at her Mac hitting buttons in mad frustration, and I grabbed a bottle of lube and lifted her rump ever so gently. With great care I began massaging the lube into her anus, and then as the rosebud parted I slipped my member deep inside her luscious rear canal and pumped.
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.
1 Intel-based Mac
AD 2006
1 quartic polynomial post
1, 1, 2006 and 1 are the zeroes of
--polynomial_zeroesYes 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
I wonder if he is going to re-release clerks enhanced with imovie hd now?
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.
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."
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.
Best Buy can have you arrested
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).
Bummer! I guess that rather implies that even with dual cores raplidly taking and Apple typically taking the high-performance road, that Apple is going to have cheap single processor Macs as well. Wish they'd have set the bar a bit higher, all things considered.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
This may border as OT, but I beleive a lot of people tend to jump to conclusions on these things, and agree with the parent post. I don't see apple outright replacing gcc, but could see them having an option in xcode to use ICC instead of GCC...
Intel has a very good compiler, if you are targeting only "Genuine Intel" CPU's other than that, YMMV.
Michael J. Ryan - tracker1.info
"Intel's Mac OS X tools are still in the early stages of development, and Intel has not completed fingering CmdrTaco's asshole yet."
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.
/.> 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.
Ask AMD.
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.
my left nut is blue
It isn't Apple that is announcing these tools. It is Intel that is touting them.
Apple has been silent.
I know it is /., but you might want to consider reading the occational article.
SteveM
The Mac OS X compilers and libraries will require Apple's prototype Intel-based Macs hardware and won't run on generic PCs, he said.
:)
Sounds like a challenge. Though it probably doesn't have the same appear as getting OS X to run on generic x86 boxes..
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.
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'? ;-)
"Apple will still be using GCC."
This is unlikely. They will probably provide gcc. But for their own builds of OSX, I would expect Apple to move towards Intels' tools. They are very well known for being significantly better than gcc.
Or in otherwords, I expect Apple to use this to provide a significant overall performance boost to OSX. Apple will be able to say "Hey - look how much faster we are than Linux!".
The only thing I look forward to with this is seeing better Mac OS vs Windows Benchamrks.
imagine a setup runing on almost identical x86 hardware running apps and OSes compiled on the same compiler to get a better idea of who makes a faster OS for running application X.
...Intel sabotaged their own compilers to make their output run badly on AMD processors.
Doesn't matter, since OS X won't (officially) run on AMD processors.
Add to that, we are going to be supporting both PPC and X86 on the Mac for many years to come.
ICC won't prevent you from building universal binaries, so I don't see much of an issue here.
Does Intel's compiler even have solid Objective-C support?
It has no Objective-C support at all.
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.
Yes, its good, but not as cross platform as something like python.
---- Booth was a patriot ----
Having a common CPU and compiler helps, but to really facilitate cross platform development, all the platforms should use the same hardware and operating system as well.
Now that's an announcement I'd like to see. If Intel went ahead and added ObjC support, then I'd suspect Apple of maybe switching compilers. However, I suspect that their huge efforts put into GCC, plus the value of having the source themselves, will keep Apple with GCC for a long, long time.
I don't care about them. They don't have a chance against Windows (and I think OSX is 235253 times better) if they can't supply the population with cheap computers, that they can make available with great supply. They don't have the manufacturing capability to do that yet... if they start specifying hardware, we should be able to build our own, or at least buy a HP Macintosh or something.
:(
I want a Mac, but I'm not paying such a premium to have one. It would just be a toy until it gets more support since none of my work apps would run on it
The price is always right if someone else is paying.
...millions of Java programmers look up, glance at the hardware changes, and get back to work.
Will Mac be any more successful than MS at preventing Illegal copies of there OS?
If you could reason with religious people, there would be no religious people
Correct - it probably won't hunt down all copies of GCC installed on your machine and remove them.
Whether it will itself build universal binaries is another question. I would be extremely suprised to hear that it does (even with that stuff about Altivec in the article; I suspect either the author, or some Intel spokesperson whom they asked about Altivec, was confused).
Perhaps you can build the PPC version with GCC or XL C/XL C++, the x86 version with ICC, and then lipo them together.
I thought PPC's could be built by anyone - the key seems to be power usage, and size???? Maybe Intel can build something that can compete with IBM and MOT and better integrate with its other chip sets.
"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."
You've forgotten about WINE, whe purpose of which is to provide a portable Win32 environment.
And then Squeak!
.NET is trying to be another one of those VM engines. (Virus writers just LOVE it. You can now infect _anything_ and still end up 'owning' a machine a couple of steps down the line.) Everything on the Windows side is trying to run with the w-i-d-e architecture (as opposed to the narrow and focused architectures that you get with real OOP) for its virtual machine.
Virtual machines are an old technology (remember UCSD Pascal with their PCode machine specification?)
Java benefitted from the hype that surrounded anything coming from Sun Microsystems in the 'nineties. Apart from the fact that it was easier for managers and PHBs to control lines of code as deliverables, which doesn't work with real lazy evaluation OOP because you sometimes end up with -x lines of code on a project, the Java VM was really no great shakes.
The Smalltalk VM is still a couple of light years a head of Java's MV. They've been at it longer, is all.
Nowadays
It still isn't perfect. They are trying to do too much with objects and ignoring relationships.
They embed pointers, a real nono, and references at their own peril. They have to refactor and reimplement every couple of years because, while the objects haven't changed, the relationships and the connections which implement them are still not being recognized as first class objects.
While it might seem a lot more complicated to track your code that way, it just requires a different point of view.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Many of the comments are talking about GCC being the answer to cross-platform development. But the question was is the availability of ICC the start of cross-platform development? If you are a software development company that only uses ICC (are there such animals?) then I would think the answer would be "very likely".
The NSA: The only part of the US government that actually listens.
Whether ICC will itself build universal binaries is another question.
Indeed. It probably won't.
Perhaps you can build the PPC version with GCC or XL C/XL C++, the x86 version with ICC, and then lipo them together.
That was my thought as well. But this would require actually writing a makefile (which many developers may be too lazy to do) unless Apple puts in some Xcode magic to do it for you. Let's hope for the magic.
Apple just uses off the shelf (OTS) components anyway. There's nothing about the hardware that is bleeding edge.
They just have a team with great aesthetics. Do you have the same talents for your team?
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Yet another misleading article title.
Intel Ports Developer Tools to OS X
You need to remember that there won't be an AMD-based Mac, only Intel-based Macs.
If Intel want to sabotage AMD on the Mac, they can go nuts for all I care. It's a waste of their time, but maybe their dev team are a bit bored lately.
And I just don't care about hacked copies of OS X running on AMD boxes. That's speaking as someone who both owns an iBook and built an AMD64 PC recently.
Interesting that no-one has noted this, but it says there will be no Objective-C support.
So the apps most people make will probably not see this compiler, except for tuned C code. So it'll probably mostly mean some faster libraries on the Intel macs.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Thank you, Nostradamus!
Please tell me what else Apple will be doing five years from now, since you have this mysterious power to see the future.
As far as I know, Apple have never publicly stated that they aren't going to use AMD processors sometime in the future. If that's come out, I haven't seen it yet.
Re: No Obj-C support at all.
Then it's pretty damn useless for developing Mac OS X apps, isn't it?
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.
will Apple finally stop supporting 9?
I'm just here for the sigs
This, as Apple is working on its first Intel-based Macs, due sometime in 2006.
This WHAT?
Grrrrr.
AC
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."
Yeah, Apple's design team are definitely talented.
Say Bob, we have to start doing the design for the new product again soon. Any ideas?
Mmm too lazy. Make it another white plastic cube. You know they'll praise it as a design revolution even if it is identical to the last one
Hehe yeah *goes back to counting stacks of money earned by selling crap hardware with 70% profit margins*
What about the Mac OS X on PowerPC platform? It's not like all the current PowerPC machines will cease to be used in two years.
Intel's announcement states that they will not support Objective-C. That makes it mostly useless for 50% (guestimate) of OSX developers.
I know no one cares anymore, and most are so excited, but this is sooooooooooooooo horrible.
The least Apple could have done is go with AMD, this is like Luke joining up with Darth Vader because he only has one arm.
the thing is he is still part of the Dark side.
I still can't accept this, Apple please say Psych anytime now, please.
god this sucks.
man, just when IBM really doesn't have to prop up Intel with its stupid pc division anymore.
It's okay. No need to thank me.
Why not look at what's happening around us now? Maybe Apple will bring out an AMD Mac, maybe not. It's not at all likely in the next few years though, and given that scale of time the whole issue isn't worth caring about.
Yes - it *is* bad that Intel would write a compiler that hurts AMD performance on purpose.
No - it's still not relevant to OS X in any way in the forseeable future.
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.
You still need Objective-C (or some other language with a so-called Objective-C Bridge, such as Java, Python or PERL) to be able to effectively use Cocoa. It is important to note that Objective-C _is_ C, but with some (like 4 main (and 8 rarely used)) additional directives for organizing functions and data into objects. It is absolutely amazing that Intel is not supporting this --yet it is wasting its time integrating to XCode!
Also note that the real magic in Objective-C (unlike C++) happens at runtime (like Smalltalk, from which it descends). Sounds bad, but we're in the future now Buck and this crap was ok on 25MHz 68030s back in the day. Also for you C++ freaks, Objective-C supports (but does not require) most of the C++ extensions to C, but you still will have to embrace those 4 simple Objective-C extensions to make your stuff go.
The main diff between C++ and ObjectiveC? The programmer can leverage the runtime environment in ObjectiveC if they want, whereas in C++, the runtime is largely concealed behind the scenes.
future of cross-platform development
... ... ...
You know, after a while, ignorance isn't even amusing anymore. gcc, nasm, qt, gtk, wxwidgets, more, then even more perl, python, ruby,
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
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.
Dude, I've been using NeXTSTEP since 1989, and Cocoa since they came up with the name. You don't need to explain Obj-C to me.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
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?
Get real! this aint gonna happen while people continue to lock themselves into Microsoft.
Think about it - cross platform development is not just about the compiler used - Its about the libraries and API's you are using. For example - If you were to build a video game that relied on DirectX and compiled it with intels compiler the chances of it working with Linux or MacOS will be Zero. Unless MS ports their libs to Linux and MacOS. That will never happen in a million years.
Perhap - just maybe WINE may get to a stage where you can drop in replacements but its a HUGE gamble.
Electronic Music Made Using Linux http://soundcloud.com/polyp
Microsoft and Intel are not friends. They are two companies that seemed to have stumbled upon a huge monopoly that they have to share. With NT 3.51/4.0, Microsoft tried to kick Intel out of its position with cross-platform support, and failed. Intel doesn't have a full monopoly because of AMD.
Basically, the closer you are to a monopoly, the more excess profits you get. Intel can't extract huge profits because AMD provides competition and MS grabs a big chunk.
Competition for OSes means that the excess profits can flow back to hardware, where Intel wins.
Remember, MS moving the XBox to the PPC is HUGE, because it means that they are getting some developers at least to support Win32/PPC, and I wouldn't rule out a run at PPC computers from MS... Hell, they could do it as MS hardware, and grab all the profits.
Competition is good for consumers. This is what we've been missing during the 10 year run (Win 95 - present) where MS and Intel monopolized the computer market.
Alex
That was +5 FUNNY
Assuming your code will compile both with GCC and with ICC, it's very easy to build a PPC binary and an x86 binary separately, and combine them into a Universal binary at the end.
Some developers I know of are planning to use this same strategy to keep their CodeWarrior projects for PPC, and use Xcode for their x86 builds.
-Mark
It's fairly trivial to add what we call a "Run Script build phase", which allows you to call any command-line tools as a part of your build. You'd simply make the PPC and x86 binaries separate targets in Xcode, and have a third "Universal" target that just combines the two.
It could certainly be made easier to do this from the standard GUI, but it's not too hard right now.
-Mark
This due. Duh! :o)
Apple has no desire to sell their OS for profit in a sense. Yes, they sell upgrades for a more reasonable $129, but their bread and butter is the hardware itself.
Apple Mice, Apple Monitors, Apple iPods, Apple Computer... They do sell software that doeshave protection such as Final Cut Pro and a few things like that, but to Apple as long as the OS only works on Mac hardware there is no need to copy protect the software.
The Apple hardware is the friggin dongle after all!
Also... Remember this and say as a mantra:
Software copy protection does not stop software piracy, it only annoys and gives greif to legitimate paying customers.
If you want to pirate something it's only mouse clicks away on google and a swift download of a cracked patch that totally undoes whatever flavor of the month software copy protection they've come up with.
Sometimes legitimate customer often will buy the software, install it and then run the cracked patch just so they can run without having to jump through hoops of fire to get the software to work.
"I am the king of the Romans, and am superior to rules of grammar!"
-Sigismund, Holy Roman Emperor (1368-1437)
I think that good cross-platform apps come with Apple re-releasing Yellow Box for Windows (probably integrated into a new release of QuickTime, so that Cocoa apps for Windows will simply state "Requires QuickTime 8" or some such thing).
I'm crossing my fingers, but I'm not holding my breath.
But the question was is the availability of ICC the start of cross-platform development?
And the answer is "no".
The start of cross-platform development was back in the '60s with Fortran, a language that - however horrible in general design and in all its ghastly details - was sufficinetly powerful and well standardised to allow people to write working programs that would run on virtually every platform.
It soon became the norm for vendors to make damn sure that developers could easily distinguish portable code from extensions. The current environment where Microsoft's business model depends on people getting enmeshed in a twisty maze of different extensions is a horrible throwback to, well, no... it was never that screwed up even when it was IBM and the seven dwarfs.
That was their motto, wasn't it?