Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Intel OS X Operating Systems

Intel Ports Developer Tools to Mac OS X 259

Posted by ScuttleMonkey from the dogs-and-cats-living-together dept.
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 discussion has been archived. No new comments can be posted.

Intel Ports Developer Tools to Mac OS X More

Intel Ports Developer Tools to Mac OS X

Comments Filter:

  • the promise? (Score:4, Insightful)

    by mov_eax_eax ( 906912 ) on Wednesday August 24, 2005 @07:10PM (#13393393)
    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.

    • Re:the promise? (Score:4, Funny)

      by foo(foo(foo(bar))) ( 263786 ) on Wednesday August 24, 2005 @07:18PM (#13393449) Homepage
      funny.... I thought it was called Java

    • Re:the promise? (Score:3, Interesting)

      by ZG-Rules ( 661531 )
      I'm not knocking GCC, it's great - but ICC creates the fastest code for Intel processors and probably the fastest code for AMD processors too. I expect a barrage of flames for saying this, but there's loads of evidence out there for it.

      Imagine an x86 Mac and a PPC64 Mac (G5) of equivalent specs, running OSX of the right flavour, both compiled with GCC. You'd expect them to both perform the same right? Now take your x86 OSX and recompile it with ICC and you get an immediate speed improvement... wouldn't you?

      • Re:the promise? (Score:5, Insightful)

        by Guy Harris ( 3803 ) <guy@alum.mit.edu> on Wednesday August 24, 2005 @09:37PM (#13394284)
        Just because Apple support GCC (and will continue doing so unless ICC for OSX suddenly becomes free or they start charging for XCode) doesn't mean they shouldn't compile their entire O/S with ICC to take advantage of the speed.

        If, however, the article is correct when it says that "The Intel tools ... will not provide a compiler for Objective C", that means that they couldn't compile the entire OS with ICC.

        • Re:the promise? (Score:5, Interesting)

          by TheRaven64 ( 641858 ) on Thursday August 25, 2005 @04:47AM (#13395955) Journal
          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.

      • Re:the promise? (Score:3, Informative)

        by 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 al
    • Yes, its good, but not as cross platform as something like python.

  • Intel Ports Developer Tools to OS X (Score:5, Funny)

    by Dorsai42 ( 738671 ) on Wednesday August 24, 2005 @07:10PM (#13393397)
    Wow, who'd have expected something like this?

  • What is old is new again (Score:5, Informative)

    by jockm ( 233372 ) on Wednesday August 24, 2005 @07:10PM (#13393399) Homepage
    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.
    • The application could have multiple binaries.

      OS X calls these fat binaries, which 10.4 supports for the ppc and ppc64 architectures. The switch to Intel will add i386 and, presumably, x86_64. However, the article states that Intel compilers will not support ppc.

      At Apple's WWDC, Steve Jobs made much of the simplicity of building universal binaries, an extension of the fat binary concept. It will be interesting to see if ISVs that use ICC deliver them. It should still be possible, but it may not be the on

  • ho hum? (Score:5, Insightful)

    by Anonymous Coward on Wednesday August 24, 2005 @07:12PM (#13393407)
    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.

  • Crossplatform? (Score:5, Insightful)

    by klingens ( 147173 ) on Wednesday August 24, 2005 @07:13PM (#13393411)
    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

    • Cross-platofrm compatibility is not limited to getting the app to compile and run - for anybody to really look at it, it has to run well. Carmack, for example, attributes the PPC-Mac performance shortfall to many things, and one of them is that GCC is not as well-optimized as visual studio or Intel's tools. So, having a really, really good compiler is going to help developers quite a bit.

      On windowing, Swing and GTK both run on Win32/Linux/OS X. You're up a river if you develop for Cocoa though. Of course,

  • The future is sort of here... (Score:5, Insightful)

    by wealthychef ( 584778 ) on Wednesday August 24, 2005 @07:14PM (#13393418)
    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?"

    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.

  • before anyone says it (Score:5, Informative)

    by ArbitraryConstant ( 763964 ) on Wednesday August 24, 2005 @07:16PM (#13393439) Homepage
    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 could have sworn that a lot of Intel's compilers were already included with Apple's Development system.

      err, nope. I guess I can say that this was already known in *June*:

      Intel plans to provide industry leading development tools support for Apple later this year, including the Intel C/C++ Compiler for Apple, Intel Fortran Compiler for Apple, Intel Math Kernel Libraries for Apple and Intel Integrated Performance Primitives for Apple.

      Source: http://www.apple.com/pr/library/2005/jun/06intel.h tml [apple.com]
      • "Intel plans to provide industry leading development tools support for Apple later this year, including the Intel C/C++ Compiler for Apple, Intel Fortran Compiler for Apple, Intel Math Kernel Libraries for Apple and Intel Integrated Performance Primitives for Apple."

        Nothing in there says that ICC will be the default compiler in XCode.

        I never denied that it would be available, only that it would be the default.

  • A Big Deal (Score:5, Interesting)

    by Nom du Keyboard ( 633989 ) on Wednesday August 24, 2005 @07:17PM (#13393443)
    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:A Big Deal (Score:5, Insightful)

      by Darth ( 29071 ) on Wednesday August 24, 2005 @07:30PM (#13393528) Homepage
      Now that all the major options for desktop systems run on intel, they want to see os competition. Erosion of Microsoft's desktop monopoly by Apple no longer equates to loss of market share for intel. Now they'd like to see Microsoft's influence reduced and be the only 800 lb. gorilla in the x86 world.

      I dont think they are focused on IBM powered consoles as much as they are focused on being the last monopoly standing in the desktop market....or at least making sure that if AMD takes them down in court, nobody else is standing either.

      • Now they'd like to see Microsoft's influence reduced and be the only 800 lb. gorilla in the x86 world.

        Don't ask me why, but it just dawned on me: where the phrase "800lb gorilla" came from. Why isn't it 1000 lbs or some other animal?

        P.S. This is a serious question... I did some googling around but no joy.

      • 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 pr

    • Re:A Big Deal (Score:5, Insightful)

      by harlows_monkeys ( 106428 ) on Wednesday August 24, 2005 @07:44PM (#13393599) Homepage
      Intel has been trying for years to advance the PC, but they keep getting held back by the mass-market nature of the platform. People would rather have older technology very cheaply than better technology that costs more.

      With Apple, they've finally got a company that doesn't care about all that legacy PC crap. Apple will build the x86 machines that Intel has always wanted.

      That's why Intel considers this to be such a big deal.

    • Doubtful. More likely Intel's trying to showcase Apple as what computers can be if they're running Intel technologies. Premier boot technologies, faster performace per watt, etc.

      It's a pretty big win for Intel to get Apple on its side. Apple is widely known for leading the computer industry to new technologies, and pairing that with Intel's top-selling chip platform is a marketing bonanza. And it's sad; IBM gave it up for little or not cost.
    • 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

      So another way to say that is that, with Apple's business, Intel found an easy way to increase it's volume by 10%.
    • I believe in Intelligent Design. It was all done by Benevolent Space Aliens. How else can you explain Tom Cruise?

      Blasphemer! The Space Aliens are neither intelligent nor benevolent. It was the Flying Spaghetti Monster [wikipedia.org]! Repent!

      Ramen!

    • Re: (Score:3, Insightful)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion

  • Cross-Platform Development (Score:5, Insightful)

    by linguae ( 763922 ) on Wednesday August 24, 2005 @07:18PM (#13393447)
    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?"

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

    • cough... Darwin and fink thrn....
    • 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.

      Only if you want to deal with all that. :) If you'd rather not, you could use wxWidgets [wxwidgets.org] (or wxPython [wxpython.org]) which give you cross-platform native interfaces without doing theming and emulation. I think those who want to do cross-platform have it pretty good these days (although

  • Bummer! (Score:3, Insightful)

    by Nom du Keyboard ( 633989 ) on Wednesday August 24, 2005 @07:26PM (#13393499)
    Intel will provide Mac tools for both single-core and multicore processors based on Intel's latest compiler technology.

    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.

  • Short answer? No (Score:5, Informative)

    by Sycraft-fu ( 314770 ) on Wednesday August 24, 2005 @07:34PM (#13393543)
    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 (Score:5, Interesting)

      by Slack3r78 ( 596506 ) on Wednesday August 24, 2005 @07:52PM (#13393650) Homepage
      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:Short answer? No (Score:4, Informative)

        by mattjb0010 ( 724744 ) on Wednesday August 24, 2005 @08:16PM (#13393780) Homepage
        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 [ppcnerds.org]. This also applies to gcc4.0 on x86 with SSEn.
        • a fallacy that all Mac apps are magically faster because the chip has AltiVec

          Not a complete fallacy since there is plenty of OS code that does use AltiVec when it's available, and this code is commonly used by nearly all apps (i.e. graphics rendering and so on).
      • There've already been a lot of reports that OS X on x86 is faster than on PPC

        Keep in mind that the reports I saw also said that Windows XP was faster on the devel boxes than standard x86 computers, even though the guts of the devel box is mostly a standard x86 computer.

        I am curious how the final x86 version will compare. Some say that the x86 version doesn't load a lot of extensions because they aren't available, others say that x86 is just faster.

        I'm not sure if I can accept the second claim at face-value

      • Re:Short answer? No (Score:3, Interesting)

        by Lars T. ( 470328 )
        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.

        Yup. The FORTRAN compiler often does some good autovectorization. Show me the C compiler does too.

        Hell, why not look at this [pixelglow.com]? Ignore the Mac part, just look at the x86 results. Looks like ICC doesn't even beat Visual C++ for most of the tests they did here (at least not by much).

        Apart from that, you can do some wierd-ass stuff wit

    • The great value of this news is that Intel's First-rate Fortran and Math libraries will be available for the Mactels as soon as they ship. This will ease the transition for scientists, as their codes can be rebuilt and tested on the early Macs, before the replacements for the PowerMacs and XServes ship in '07.

      No, it's not XLF, which I would have preferred, but IFort is capable of producing screamingly fast code that generates correct results (generally; there are always the first couple releases of a ne

  • Yeah, sure. (Score:2, Insightful)

    by Anonymous Coward
    /.> 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.

    • Re:Yeah, sure. (Score:3, Informative)

      by Guy Harris ( 3803 )

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

      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*

  • No (Score:5, Informative)

    by harlows_monkeys ( 106428 ) on Wednesday August 24, 2005 @07:37PM (#13393569) Homepage
    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.

  • Who will use this? Not me! (Score:3, Informative)

    by Zobeid ( 314469 ) on Wednesday August 24, 2005 @07:49PM (#13393630)
    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.
    • ...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.

      • 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

        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, wa

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

  • AltiVec ona a x86 compiler? (Score:3, Insightful)

    by Squashee ( 573673 ) on Wednesday August 24, 2005 @07:53PM (#13393657) Homepage
    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 Apple first announced the switch to Intel, there were various comments here and there about... "does Apple get to walk away from the AIM (Apple-IBM-Motorola) alliance with any IP ?"

      No one (except the members of the AIM alliance) know for sure who has the rights to what. Wouldn't it be insanely funny if Apple got the rights to Altivec because IBM could not meet the agreed to performance timetables. I know this is really blue-sky conjecture, but that would make the MacTel chips scream. Especially with th
    • That part of the article is just confused; it's best to just ignore it altogether.

    • Re:AltiVec ona a x86 compiler? (Score:5, Interesting)

      by Matthias Wiesmann ( 221411 ) on Wednesday August 24, 2005 @09:03PM (#13394085) Homepage Journal
      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.

  • Cross-platform development started in 1996 (Score:4, Informative)

    by teutonic_leech ( 596265 ) on Wednesday August 24, 2005 @07:55PM (#13393663)
    Remember - a little-known language called 'Java'? ;-)
    • Huh, Java wasn't the first to the game. Remember a little-known language called "interpreted?"

      Java was just the first thing that made it feasible to do serious commercial, closed-source cross-platform development.
      • And then Squeak!

        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

  • So PPC machines get left behind (Score:3, Interesting)

    by SiliconTrip ( 465961 ) on Wednesday August 24, 2005 @08:26PM (#13393845) Homepage
    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.
  • 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.

  • Will Mac be any more successful than MS at preventing Illegal copies of there OS?
  • 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".

  • Can't wait (Score:4, Interesting)

    by wandazulu ( 265281 ) on Wednesday August 24, 2005 @11:10PM (#13394889)
    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.

  • This is terrible (Score:3, Insightful)

    by iopred ( 815810 ) on Thursday August 25, 2005 @03:58AM (#13395858) Homepage
    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.

Slashdot Top Deals

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Close