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

the promise?

[mov_eax_eax]

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?

[foo(foo(foo(bar)))]

funny.... I thought it was called Java

Re:the promise?

[Usquebaugh]

I think you meant to say SmallTalk?

Re:the promise?

[McGiraf]

Assembler?

Re:the promise?

[ZG-Rules]

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?

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.

Re:the promise?

[i.r.id10t]

No.. JavaScript!

Re:the promise?

[Anonymous Coward]

ICC creates the fastest code for Intel processors and probably the fastest code for AMD processors

Despite the fact it does not acknowledge SSE2 on AMD64 processors?

Re:the promise?

[ToasterofDOOM]

I don't know about ICC, but GCC is good and all, yet it has its downsides. For example, it is very poor at vectorizing code, which is a must for Apple.

Re:the promise?

[Orion Blastar]

I thought it was Mono?

Re:the promise?

[FLAGGR]

Oh fuck. I read that as Apple ports developer tools to OSX. How embarassing. I assumed maybe they weren't there, and everyone was crosscompiling for x86 on their ppc's. Crap. Sorry man :(

Re:the promise?

[Anonymous Coward]

This here is a great example of why there's no need to be so mean to people. FLAGGR comes off looking like a huge jerk simply because he wanted to be mean to mov_eax_eax. Even if mov_eax_eax had been wrong, correcting him politely would have been much nicer than the venomous reply that was actually posted.

No one is going to think you're cool just because you're mean to someone. You'll get more respect if you reply in a nicer fashion; and who knows, maybe the politeness will come back to you in the future.

Re:the promise?

[Guy Harris]

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?

[Mr. Jaggers]

Befunge, anyone? I hear it's pretty cross platform... maybe Intel will make an optimized Befunge compiler, and a new day will dawn...

Re:the promise?

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

Re:the promise?

[Frumious Wombat]

Of course, the G5 Mac could have its OS compiled with IBM's XLC, and the race would be on.

That's the depressing thing about this change. ICC/IFORT are capable compilers and all, but IBM's compilers ported to OS-X were in a class by themselves. Extremely fast, extremely fast, extremely stable, and compatible with the flags from the AIX versions.

That's what cross-platform means, right? Runs on everything from Macs to AIX-based mainframes.

Re:the promise?

[Anonymous Coward]

Either way, I don't see how the "future of cross-platform development" is suddenly going to be here because intel ports their shit to mac. Intel is behind on processor performance and the marketshare of macs is irrelevently small.

Yet another mac fanboi article on /. Why am I not surprised?

Re:the promise?

[Alan Partridge]

+1, Nasal Tea Ejection

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.

Re:the promise?

[master_p]

It's also called Java.

Re:the promise?

[Anonymous Coward]

Python?? Tcl??

Re:the promise?

[Anonymous Writer]

Um... REALbasic?

Re:the promise?

[BoomerSooner]

I'd be more concerned with windowing toolkits than the Intel Compiler. WxWindows, QT, etc. provide more in the way of a cross platform development environment. Although when programming for Mac OS you still need to change the location of almost every menu item and button on a form to conform with the design standards used on that OS. I found the buttons being switched a bit irritating at first but once you are familiar with the locations it's no problem.

Re:the promise?

[empaler]

Yet another uninsightful troll on /. Why am I not surprised?

Re:the promise?

[aug24]

You can both win: GCJ

Re:the promise?

[zygote]

I don't know if this is on point or not, but two things come to mind. As a user of both platforms (with infinitely greater preference to OS X) it is also annoying to have the buttons and other widgets in different locations.
Second, I'd bet those different locations came as a result of Microsoft knowing they couldn't completely rip-off the Mac's "look and feel" so they scrambled things way back in the day. Paid off since they won that court fight.

Re:the promise?

[Anonymous Coward]

On the possibility that you're actually serious, and have forgotten, or never had the benefit, of basic computer architecture course in college, here's an FYI: your idea, assembler is the only one, out of all the other posts (Java, TCL, Pascal, C#, C) that, like on the old sesame street game, clearly does not belong. As the other posters have pointed out, crossplatform is nothing new.

Re:the promise?

[McGiraf]

I was not serious...
... the mods were right! They got it! Wow is this slashdot? or am I lost on the interweb? Imagine that a cluster of interweb in soviet Russia browses YOU!

Re:the promise?

[BoomerSooner]

Imagine if we had fucking software patents in the 80's. Apple would rule the world (assuming Xerox PARC wouldn't have patented it first).

Re:the promise?

[Bert64]

Intel have always been behind on processor speed, nothing is new here.. The risc chips all used to beat intel hands down, and it took a couple of years for intel to catch up even after development on these chips stopped, the last of the alpha chips can still beat intel's finest in some areas..
Intel just can't lead, they never have, they've always been a stage behind in performance, and relied on price and existing reputation.

Re:the promise?

[Bert64]

Well, it might be easier to make the interface using a cross-platform toolkit, and have it customiseable.. so you can choose a layout to suit your individual taste.. some of us might like the mac way of doing things, despite not having any apple hardware at work to run osx on.

Re:the promise?

[JohnGalt00]

On AMD systems, ICC is insignificantly faster.

Remember that AMD recently complained that ICC detected the CPU's manufacturer instead of the CPU's feature set when doing optimizations. The result looked something like this:

if(CPU == "P4")
        P4optimizations();
else if(CPU =="P3")
        P3optimizations();
// and so on,
else if(CPU == "386" || Maker == "AMD")
        386optimizations();

when it should have looked like like

if( hasSSE3())
      SSE3optimizations();
else if (hasSSE2())
      SSE2optimizations();

The problem isn't that AMD cpus can't gain from Intel's compiler, but that Intel specifically excluded them from the compilier's optimizations. Obviously the second version benefits AMD a lot more, because then the intel compilier produces optimized code for AMD cpus as well.

Re:the promise?

[gig]

Obviously you are referring to Flash.

Re:the promise?

[Orion Blastar]

Pilot, Logo, and MUMPS. Those are the way to go, to the extreeeeeeeeemmmmmmeeee!

Intel Ports Developer Tools to OS X

[Dorsai42]

Wow, who'd have expected something like this?

Re:Intel Ports Developer Tools to OS X

[piano-in-a-box]

It's almost like...Apple switching to Intel processors. But they'd have to be crazy to do something like that!

What is old is new again

[jockm]

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.

Re:What is old is new again

[_|()|\|]

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 one-click operation that Steve promised.

Re:What is old is new again

[feijai]

Correction. While NeXT had fat binaries, they were of course restricted to the operating system and file system. So while you could have an app bundle that ran NeXTSTEP on Black 68K hardware, PCs, Suns, and HP's, it couldn't also have OpenStep for Win32.

Re:What is old is new again

[Anonymous Coward]

mod parent up yo

Re:What is old is new again

[ucahg]

I hope that Apple and Intel will provide hooks so the fat binaries can be compiled for PPC using the standard GCC-based compiler, but use Intel's compiler for the x86 code. Best of both worlds, no?

Re:What is old is new again

[Anonymous Coward]

Get your own mod points and some proper language, yo

Re:What is old is new again

[_|()|\|]

Maybe Jobs doesn't like his apps being called fat?

OS X 10.4 uses fat binaries. For example, Apple recently botched a security update by failing to ship a fat binary for the BSD layer. This is what it's supposed to look like:

$ file /usr/lib/libSystem.B.dylib
/usr/lib/libSystem.B.dylib: Mach-O fat file with 2 architectures
/usr/lib/libSystem.B.dylib (for architecture ppc): Mach-O dynamically linked shared library ppc
/usr/lib/libSystem.B.dylib (for architecture ppc64): Mach-O 64-bit dynamically linked shared library ppc64

Apple's GCC has built-in support for fat binaries:

$ gcc -o hello hello.m -arch ppc -arch ppc64
$ file hello
hello: Mach-O fat file with 2 architectures
hello (for architecture ppc): Mach-O executable ppc
hello (for architecture ppc64): Mach-O 64-bit executable ppc64

If I had the right SDK installed, I could have added -arch i386. Building fat binaries with GCC and ICC will probably require the use of lipo(1).

Re:What is old is new again

[Pope]

And remember, back in the day, PPC and 68K combined native apps were also called Fat Binaries.

Re:What is old is new again

[feijai]

I am under the impression that NeXT's method for supporting multipe architectures with one .app was to have a binary for each different archtecture stored in a separate subdirectory within the .app. Was this not the case?

It is not the case. NeXT's "app wrappers" stored subdirectories of resources, and within resources there were further subdirectories (.lproj) for different languages. But the executable proper was a single file in Mach-O format which contained multiple architecture binaries. Likewise for the various loadable bundles' object files.

Re:What is old is new again

[Bert64]

Or they could use IBM's XLC for PPC.. XLC is to PPC what ICC is to x86..

Re:What is old is new again

[Bert64]

But it could have had openstep for solaris, the limitation with win32 is that the executeable must be a binary program with a filename ending in .exe or .com etc, openstep apps are directories ending in .app with the real binaries and support files inside, although openstep and unix based os's have no requirement on this

Re:WTF?????

[larry bagina]

No, intel is porting their x86 compilers to run under MacOS/intel. The same compilers that already run under windows and linux.

Apple will still be using GCC.

ho hum?

[Anonymous Coward]

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.

Re:ho hum?

[larry bagina]

It also includes a Fortran compiler.

Re:ho hum?

[Deviant Q]

It always seemed to me like that was a major selling point of .NET...

Re:ho hum?

[javaxman]

So what's this going to compile? Core Foundation apps and Carbon apps without any vector code?

Just a wild guess, but what is most of the Darwin codebase ? Oh...

Re:ho hum?

[jericho4.0]

Doesn't gcc compile Objective-C to C first? Either way, I'm sure a front end wouldn't be too hard, and quite needed, as you note.

I hope Apple sticks with gcc.

Re:ho hum?

[zephc]

I seem to recall that the first ObjC compiler by Stepstone translated to C, but modern ones go straight to object code, although a number of support functions are in C (like objc_msgSend(); )

Re:ho hum?

[5plicer]

How can there be no IOKit??? IOKit is part of Darwin (which is open source).

Re:ho hum?

[TheRaven64]

The Portable Object Compiler works like this, but is not compatible with OpenStep platforms (GNUstep and Cocoa currently) which somewhat limits its usefulness.

Crossplatform?

[klingens]

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

Re:Crossplatform?

[Deviant Q]

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

Is that really true? (I really haven no idea, am asking for information). So I could compile some basic C++ program (e.g. loop from 1 to 10) in gcc and it would work on Windows and Linux? I suppose support for things like <stdio> is too much though, right?

Re:Crossplatform?

[Anonymous Coward]

So I could compile some basic C++ program (e.g. loop from 1 to 10) in gcc and it would work on Windows and Linux?

Yes.

Re:Crossplatform?

[Deviant Q]

Huh, very cool. I was always under the impression there was something specific to each platform in the header file. You know how Microsoft always talks about "PE" (Portable Executable) files as their unique format.

Re:Crossplatform?

[wayne606]

Batch programs (i.e. no GUI) that use standard C and C++ libraries, and the more vanilla Posix calls, are very portable among Win, *nix, Mac, etc. You run into problems with makefiles, libraries, Fortran to C linking, graphics, etc.

Re:Crossplatform?

[Anonymous Coward]

Assuming I'm not being trolled, I misunderstood your question. You would have to compile your simple program twice, once on Windows and once on Linux to create two binaries.

In other words, a simple C++ program would be source compatible, not binary compatible.

Re:Crossplatform?

[mrchaotica]

Speaking of linking Fortran to C, do you know any good online resources about that?

Re:Crossplatform?

[Guy Harris]

You would have to compile your simple program twice, once on Windows and once on Linux to create two binaries.

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.

Re:Crossplatform?

[happyemoticon]

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, there's a lot more libraries someone would concievably call than STL and a windowing system.

Re:Crossplatform?

[Guy Harris]

Batch programs (i.e. no GUI) that use standard C and C++ libraries, and the more vanilla Posix calls, are very portable among Win, *nix, Mac, etc.

The more vanilla POSIX calls should work among *nixes (Mac OS X is a *nix). Some more work would be needed to make them work on Windows. (MSVC++'s libraries have versions of at least some of those calls, but I think their names begin with an extra "_".)

Re:Crossplatform?

[larry bagina]

Linux uses ELF format for executables and libraries. *BSD, Solaris, SCO Unix, and some other 386-based ones can support linux binaries.

windows does use the PE format, and won't run elf binaries. You can, of course, use WINE to run PE binaries under linux.

Re:Crossplatform?

[Anonymous Coward]

I know of, for example, no "inverse Wine" to let you, for example, run Linux binaries on Windows

Well, there's http://www.colinux.org/, a port of linux to
WinNT 5.x. This is different to VMWare or cygwin or qemu or bochs or xen, it's more like wine (only it can be based on real sources instead of reverse-engineered APIs) - and yes, you can run ELF format linux/x86 binaries on windows with it.

Re:Crossplatform?

[Anonymous Coward]

There actually is a reverse WINE, called LINE. The real difficulty in running a binary from one system on another is translating the system calls. Almost any modern 32/64-bit demand pages OS loads an object file by just mapping it in memory.

Just change the way the header is interpreted and jump right in. As with anything, the devil is in the details.

Re:Crossplatform?

[Sketch]

> You would have to compile your simple program twice, once on Windows and once on Linux to create two binaries.

You would have to compile your program twice, but technically you could do both builds on either system, as GCC can be set up to cross-compile.

Re:Crossplatform?

[tbone1]

• Speaking of linking Fortran to C, do you know any good online resources about that?

Uh, fifteen years ago at NASA we were using make to compile the .f and .c files to .o files and "assembling" the .o files into an executable. That should still work, since it's what the GUI development tools are doing in in the background anyway. Of course, back when I was doing that work, the world was in black-and-white and we had to make our own flint-knapped keyboards.

Re:Crossplatform?

[Haeleth]

there's http://www.colinux.org/, a port of linux to
WinNT 5.x. . . . you can run ELF format linux/x86 binaries on windows with it.

No you can't. The only binary that CoLinux itself runs is the Linux kernel itself, which it actually runs kind of alongside Windows rather than in it: you then run Linux binaries in Linux itself.

As far as any programs you actually run are concerned, the situation is basically identical to having two computers side by side, networked together. Want a Linux shell? You get it by sshing across a virtual network into the virtual Linux box. Want Linux GUI programs on your Windows desktop? You do it by running a Windows X server and launching the Linux applications "remotely".

Look at it in terms of the problem the software solves, and it's clear that CoLinux is much more similar to a "headless VMware" than to anything like WINE.

The future is sort of here...

[wealthychef]

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.

Re:The future is sort of here...

[Anonymous Coward]

Yes, if you define "cross platform" as being restricted to Windows, Mac and Linux

Hell, it's an improvement over the current meaning of "cross platform", which is "Windows 95, Windows 98, Windows 2000 and Windows XP"

Re:The future is sort of here...

[Geoff-with-a-G]

Yes, if you define "cross platform" as being restricted to Windows, Mac and Linux.

Why shouldn't I? Google does.

Cross-platform means "runs on more than one platform." Windows, Mac, and Linux are more than one platform, and an app that would run on new Macs as well as Windows and Linux is pretty impressive. If you want to define "cross-platform" as "runs on all platforms", then I don't think anyone has ever developed a cross-platform application.

Re:mirror

[Deltaspectre]

I really think eWeek isn't going down anytime soon, save your function for some other day :)

Mod down, troll in article

[bonch]

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.

Re:Mod down, troll in article

[birge]

Mod down, my ass. Mod the fucker up, funny. These tech articles need a little more action, anyway.

Re:Mod down, troll in article

[Kenshin]

Seriously.

That troll caught me completely off-guard, and I nearly fell out of my seat.

before anyone says it

[ArbitraryConstant]

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.

Re:before anyone says it

[ufnoise]

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.

The intel compilers are free for non-commercial use. At least on linux and I'm pretty sure for windows.

Also, it is always a good idea to test your code on as many different compilers as possible. This makes sure that it will be easier to port later on.

Re:before anyone says it

[ArbitraryConstant]

"The intel compilers are free for non-commercial use. At least on linux and I'm pretty sure for windows."

Using ICC by default would make XCode non-free for commercial use.

"Also, it is always a good idea to test your code on as many different compilers as possible. This makes sure that it will be easier to port later on."

I won't deny that, but for people doing Mac-only development it would introduce a lot of extra effort and platform-specific bugs. It would be foolish to do it by default. Apple needs to minimize the differences between platforms, it's already going to take a non-trivial amount of extra effort to maintain a universal binary.

Re:before anyone says it

[Jeff DeMaagd]

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

Re:before anyone says it

[ArbitraryConstant]

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

Re:before anyone says it

[convolvatron]

you wank. 'gcc compatible', yes great. you extend a language and then force all sort of people to deal with the resultant garbage. there is a standard, use it. the gcc extentions can be conveient, but they don't really change the scope of the language.

and the intel compiler can really scream over gcc in some applications, and its almost never worse. its a good compiler for a crappy instruction set. why would you not want to use it? because you're a religous fanatic?

Re:before anyone says it

[larry bagina]

the free non-commercial version is linux only. You can get a free evaluation version for windows, but you need to shell out some scratch, non commercial or not.

Re:before anyone says it

[ArbitraryConstant]

"you wank. 'gcc compatible', yes great. you extend a language and then force all sort of people to deal with the resultant garbage. there is a standard, use it. the gcc extentions can be conveient, but they don't really change the scope of the language."

Whether or not you or I think the resultant garbage is bad, sometimes people have taken advantage of it and that's enough to say they're not compatible.

"and the intel compiler can really scream over gcc in some applica0tions, and its almost never worse. its a good compiler for a crappy instruction set."

True, true, and true.

"why would you not want to use it? because you're a religous fanatic?"

Off the top of my head?

• Because maintaining an application for two different architechtures is easier than maintaining an application for two different compilers and architechtures. Even if they were both strict C compilers, they'd still be slightly different.
• Because ICC isn't free for commercial applications.
  
• Because ICC produces broken binaries for other processors. Irrelevant on Intel Mac, but if we're talking about Linux or Windows this is an issue.
  
• Because as bad as the GCC customizations are, sometimes people have used them and sometimes it's a pain to port them to another compiler.

I'm not a GNU zealot or a GCC zealot, I'm just saying that there's valid reasons to not want a different compiler. If they'd been using a commercial compiler and were considering adding GCC I'd be saying the same thing.

Re:before anyone says it

[Anonymous Coward]

you extend a language and then force all sort of people to deal with the resultant garbage.

Most of that "resultant garbage" was pulled straight into the C99 standard, right from the very first draft.

What's wrong with improving a language? Do you still write K&R style function definitions?

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:A Big Deal

[Darth]

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.

Re:A Big Deal

[harlows_monkeys]

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.

Re:A Big Deal

[ciroknight]

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.

Re:A Big Deal

[That's Unpossible!]

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

Re:A Big Deal

[grouchomarxist]

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! Repent!

Ramen!

Re:A Big Deal

[jcr]

Intel sure keeps making a big deal of this Apple deal.

Of course they are. They want people to know that the crappy user experience they get from Windows isn't Intel's fault.

Intel's been trying to get the Mac OS on their processors since 1984.

-jcr

Re:A Big Deal

[Anonymous Coward]

lol Intel doesn't care what OS their CPUs run. They're just as happy if you run Linux, much less Windows or OSX.

I think x86's marketshare speaks to the exact opposite here - they want to KEEP people using x86 chips here (which, for 20+ years was MS-DOS or Windows). Introducing Mac OS X to x86 is simply a new door for Intel to gain sales volume.

Do you think Intel wants Windows gone? Hardly.

Re:A Big Deal

[andy55]

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.

Re:A Big Deal

[rajafarian]

... that the crappy user experience they get from Windows isn't Intel's fault.

That's funny!

I almost put my first computer in the closet (Intel 486dx2-66, 8MB RAM, 1 MB Diamond video card, 420 MB HDD bought in 2/95) because I thought all computers sucked shit but fell in love with it when I found out the problem was really just Windows. I installed OS/2 (switched to Linux ~'98) and became a Microsoft basher immediately after that. ... that was also my only Intel CPU I've ever owned/bought. I'm an AMD slut.

Re:A Big Deal

[Anonymous Coward]

NO. False. The Apple x86 PC's are legacy PC designs. They will not be using OpenFirmware or getting rid of any of the legacy nonsense. The legacy nonsense these days is encased in those fancy chipsets (stuff like the A20 gate, the fact that the 8042 is necessary for reset, A20, etc).

All of that cruft is not going away -- it would be significantly more expensive to do so. Nope. I suspect when released an Apple x86 will be nothing more than a modern PC, with most things done by ACPI on top of a regular legacy BIOS. Of course, with a simple grey-on-white apple splash screen.

Re:A Big Deal

[BorgCopyeditor]

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.

The fact that no one can say where this phrase came from is the elephant in the living room.

Re:A Big Deal

[jcr]

Do you think Intel wants Windows gone? Hardly.

I don't think they want it gone, but they certainly want it to be better than it is now. There's a reason why they coughed up $10M for the NeXTSTEP port back in the early '90s.

-jcr

Re:A Big Deal

[Anonymous Coward]

Considering that 90%+ of their processors will still go into Windows-based systems that won't run OS-X

Oh, you are so wrong. Subtract 20% from that number per year for the next five years. All of this has happened before (in the minicomputer world yo!) and it will all happen again....

Re:A Big Deal

[podperson]

Considering that 90%+ of their processors will still go into Windows-based systems that won't run OS-X

Yes but which ones will be appearing in feature films? Which ones will be casually used by the stars of top-rating TV shows? Which ones will be on the desks of famous people being interviewed on TV? Apple doesn't even *pay* for a lot of this exposure.

And of course you're assuming Apple doesn't gain marketshare.

the first Apple+Intel systems are still a year away if not more

The first Apple+Intel systems are in developer hands today. I believe early 2006 is somewhat less than a year away.

Re:A Big Deal

[Anonymous Coward]

Apple will be Intel's crowning glory (despite the low market share).

1. It finally heals the split that's existed since the 80s... giving Intel's arch 100% (near enough) of the mainstream computer market.

2. The new Intel Mac will be the first PCs based around Trusted Computing -- and as such will be a spearhead for Intel's big DRM programme. Apple's introduction of these machines will legitimise the architecture (particularly with the Apple zealots blessing everything they do) and Dell etc etc will follow soon after.

Re:A Big Deal

[dfghjk]

Of course apple will be using chipsets as well as processors. They'd be foolish not to. All that PC "cruft" that people refer to ends up in the "who gives a shit" category anyway. It doesn't effect the performance of the machine and only matters to /.'ers. Apple may add some cruft of their own, but PC cruft like PCI, USB etc. have served them well.

Re:A Big Deal

[Nom du Keyboard]

So another way to say that is that, with Apple's business, Intel found an easy way to increase it's volume by 10%.

Will that be enough to offset the loss of the XBox original?

Re:A Big Deal

[That's Unpossible!]

Will that be enough to offset the loss of the XBox original?

Who knows, but it is not like those two events are mutually exclusive. MSFT chose to go with PPC for xbox 360, regardless of the fact that Apple is going with Intel in the future.

I think it is a good bet that Apple will eventually make more money for Intel than Xbox.

Re:A Big Deal

[gig]

Once Apple systems have the same CPU's as Dell, HP, IBM, etc. then the difference between Apple and the rest of the industry shifts from "Mac vs. PC" to "Mac OS vs. Windows" and that is a fight that many people in the industry think Apple will do really well in. Especially when the new Mac buyer is told that they can always run Windows on their Apple system if they don't like the switch.

Many people right now think Apple is poised to take a huge chunk of the PC market. For example, John Dvorak of PC Magazine, who has never been accused of being a Mac person or Apple supporter, has written that he expects Apple to take more than 50% of the PC business over the next five years. On the one hand Mac OS X is roasting hot and UNIX secure and on the other hand Windows Vista is freezing cold and full of viruses.

So it is quite possible that Intel thinks Mac OS X is the best thing running on Intel chips now and going forward and are putting the effort in to support the "next generation PC" running a next generation OS. Imagine a bunch of Intel executives standing around a few years ago lamenting the fact that all their hard work ends up being crashed by MS Windows and running spyware and viruses and then Steve Jobs comes by from next door and tells them that by the way Mac OS X is also an Intel-compatible operating system. What do you guys think of building some great hardware products for us to run on?

Microsoft has had their decade of Windows 95, but that's over now.

Re:A Big Deal

[gig]

The Apple Intel developer box is just a plain PC, and of course the development builds of Mac OS X have all been for plain PC's running in Apple's labs. However there is nothing stopping Apple and Intel from developing a new "Mactel" firmware/BIOS that eliminates some cruft, carries forware current Mac bootup features, and is necessary for running Mac OS X (preventing running Mac OS on plain white boxes.)

You have to be careful about speculating on what's coming in future Macs. Intel had obvious and public iMac envy in 1998, Mac OS X was running on Intel before the operating system was bought by Apple, and Apple and Intel have been working together for over a year now and there is still almost a year before the first Mactel systems even ship. These are Apple's "G6" systems and they're not afraid to drive stuff forward.

Re:A Big Deal

[Dabaobeir]

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.

According to John "Hannibal" Stokes' article on Ars Technica, it seems that Apple likes cheap CPUs, too, and even squeezed IBM so hard that IBM lost interest in the deal. It seems that Apple used to pay less than half the price of a Pentium for PowerPC CPUs. No wonder Freescale couldn't deliver on improving CPU performance.

Cross-Platform Development

[linguae]

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

Re:Cross-Platform Development

[dr_labrat]

cough... Darwin and fink thrn....

Re:Cross-Platform Development

[kollivier]

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 (or wxPython) 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 it can always, of course, be better).

As for the Intel announcement, I think the only real impact will be the first thing I heard of when I read it - speed boost for MacTel apps! (if you can afford it, that is...)

Re:Cross-Platform Development

[zhiwenchong]

Unfortunately wxWidgets isn't very mature on the Mac OS X platform. I've tried it, and it works well for very simple interfaces, but it's a bit buggy. It's definitely not for production level code.

Qt on the Mac is a lot better -- but considerably more difficult to understand.

Re:Cross-Platform Development

[kollivier]

Unfortunately wxWidgets isn't very mature on the Mac OS X platform. I've tried it, and it works well for very simple interfaces, but it's a bit buggy. It's definitely not for production level code.

Which version were you using when you tried it? If you were working with the 2.4.x branch, then you're missing out on a ton of work that has been done over the past two years to bring the OS X port in line with other ports. If you haven't tried the 2.6 versions yet, then you may really want to consider taking a second look. I work on at least 3 wxPython apps (none of them simple - I only wish!) with Mac versions either released or in progress, and they all run quite well on Mac when using the 2.6 branch.

That being said, there is, of course, more work to be done, and if you point out what problems you had, I'll be happy to try and help get it resolved. The main reason these things haven't all gotten resolved yet is that we are, of course, a community project, and our community of volunteer Mac developers has only recently started to grow to match that of other ports, just as support for the Mac platform in general has grown considerably recently.

Re:Cross-Platform Development

[BorgCopyeditor]

Have you tried Qt 4? I'm finding it fairly straightforward and quick, and I just started learning C++ a month ago. The docs aren't great, or more precisely, the really useful information can be hard to put your finger on, even if it's there. But once you get the hang of how components tend to fit together, it's impressively powerful. IMHO. IANAP.

Re:Cross-Platform Development

[zhiwenchong]

You could be right... I need to revisit wxWidgets (and esp. wxPython).

Re:Cross-Platform Development

[zhiwenchong]

Yes, I've tried Qt 4.
It's got a slick UI designer...
But apart from the fact that Qt has got it's own unique event model (which takes a bit of effort to understand) etc., it's is so geared towards the C++ way of thinking that those of us who are using it through a wrapper like PyQt find it unnatural.

Not that that's Qt's fault -- it is a C++ toolkit after all.

Re:Cross-Platform Development

[Anonymous Coward]

Learning Qt at the same time as you learn C++ will invoke major brain-damage. I mean, more brain damage than is usually caused by learning C++ alone. It's all the weird MOC shit and the completly screwy event signal/slot model. You might find it tough to seperate what is C++ from what is Qt weirdness.

I say this as a fully braindamaged C++ whore, by the way.

Re:WTF?????

[Symphonix]

Surely that means that any projects created in the Intel Developer Tools will only run on Intel macs... However the comment that "...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..." would suggest that they will be creating universal binaries and supporting PPC, allthough not using these non-Intel processors to their full potential.

Bummer!

[Nom du Keyboard]

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.

Re:Bummer!

[Wesley Felter]

As much as you would like dual-core minis and iBooks, they're probably not economically viable.

Re:Bummer!

[binary paladin]

And there are the minis as well. Dual core may be here, but Apple's low end products are still toting a previous generation processor. Woopie-doo.

Re:Bummer!

[dfghjk]

Since when has Apple typically taken the high-performance road? Performance legends in their own minds perhaps, but nothing other than slow processors in nice packages to everyone else. Even Apple recognizes that at this point.

Re:Bummer!

[TheRaven64]

They will eventually. Remember when CPUs faster than 1GHz (or 100MHz, or 16MHz, or...) were only used in the top-end machines? The same will happen with single-core, and dual-core and quad-core, etc. I would imagine that initially Apple will have single-core iBooks and dual-core PowerBooks. The differentiation between their consumer and pro laptop lines is really slim at the moment, and they would welcome the chance to increase it. Personally, I plan on hanging onto my PowerBook for a while - although I will probably be tempted to upgrade when 4-cores is standard (even if it only uses one on battery power).

Re:Bummer!

[gig]

> Since when has Apple typically taken the high-performance
> road?

- gigabit ethernet standard on pro machines since 2000
- firewire standard since 1999
- firewire 800 standard on Power Macs since 2003
- first 802.11b wireless networking in 1999
- first 802.11g networking (AirPort Extreme)
- gui running in the graphics processor since 2002
- all-digital LCD displays since 2001
- always the biggest, highest-contrast, truest color displays in the industry
- optical mouses standard since 2001
- first 64-bit desktop systems and 8 GB RAM capacity
- five hour battery life on notebooks standard since 1997
- 1+ GB RAM capacity typical on pro systems since 1999

MOD PARENT UP!

[aztracker1]

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.

Re:MOD PARENT UP!

[dgatwood]

First of all, since Xcode is free and ICC isn't, it's probably safe to assume that this Xcode enhancement would be available from Intel, not Apple, hence replace gcc, it presumably would not.

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

Re:MOD PARENT UP!

[Halo1]

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

Unfortunately, that's not true. Several people have already tried to add support for other compilers to Xcode and apart from using script build phases, there doesn't seem to be a solution currently. If you start editing Xcode's gcc description files to change them for working with another compiler (i.e., to expose the command line options via the GUI), you only get Xcode crashes.

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.

Re:WTF?????

[A.K.A_Magnet]

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

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

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? :)

Short answer? No

[Sycraft-fu]

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

[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:Short answer? No

[mattjb0010]

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. This also applies to gcc4.0 on x86 with SSEn.

Re:Short answer? No

[drfreak]

I used to scoff at the prospect of programming in VB. Even did it for a short while. Fast forward three years to just about a month ago. I checked out VB.NET for the first time. It blew my fucking mind. This IDE has actually got me interested in learning object oriented programming. The book I bought to learn from last weekend shows VB code and C# code side-by-side and I can actually understand it. .NET is really all the good things people say about it. Not only does it have the potential to be as platform agnostic as Java is, it it living up to it's full potential of being *language* agnostic, which Java was never designed to be. Who knows, Microsoft may even port Visual Studio to the Mac some day. They've done well with their Office port.

Re:Short answer? No

[GrahamCox]

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

Re:Short answer? No

[IntergalacticWalrus]

.NET will never become fully platform agnostic because it's controlled by Microsoft. Don't get fooled by the fact that the MIL is an ISO standard, that's just a nice cover. The critical aspect of .NET (and C#) is its APIs, and Microsoft made sure to pollute it with their proprietary stuff so they will always have the upper hand, on a technical AND legal level.

Re:Short answer? No

[Jeff DeMaagd]

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, esp. if a system like the Big Mac cluster kept pace with Xeon and Opteron clusters dollar-for-dollar on hardware costs.

Re:Short answer? No

[Frumious Wombat]

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 new version that seem to have issues). It's also already a standard, so the porting from Linux-x86 to Mac-x86 will go more quickly.

Does anyone know if Pathscale plans to ports its compiler suite to OS-X or not? At the moment, I believe that they lead in the X86-64 world, having started with the SGI Open64 compilers, which were based on Cray technology. It would be nice to see them as an alternative as well.

Re:Short answer? No

[Anonymous Coward]

In experience, the biggest reason why GCC hasn't been producing great results for OS X is that it doesn't know what to do with all of the PPC's registers (there are 32 32-bit integer regs, and 32 64-bit float regs). Consequently you have all the disadvantages of a large number of registers (context switches take longer, chips cost more), but the software doesn't make good use of the addition. In fact, GCC tends to stick to loading addresses from memory, performing one instruction on them, and storing the result again. If that one instruction is an add, you end up spending four times as many cycles doing loading and storing as you do performing arithmetic, even for fairly math-heavy routines.

Re:Short answer? No

[drfreak]

That might be true, but projects like Mono exist for that reason. Besides, not everything proprietary is evil. I wouldn't mind non-free .NET if it ran on my PowerBook VIIV.

Re:Short answer? No

[el_womble]

I don't really give a damn about ICC coming to Mac for exactly that reason. Your quite right, VS is a great IDE, and was one of the very few reasons I seriosuly concidered staying with the windows platform.

However, (puts Mac zealot hat on), Xcode isn't that far behind, and in a few areas its better. As an ex .Net developer I can say that for desktop apps Cocoa and the Core Frameworks are without equal on any platform(YMMV). I didn't think C# could be topped, I threw 10s of little apps together for friends and family, because it was almost as easy as drawing the interface on a piece of paper and throwing a little of code in the background. Cocoa takes away the even more of the code bit. Core data could change your life.

I would really like to see XCode ported to Windows, Linux and BSD. However, I think its unlikely to happen. But if there is one thing that Sun got right it is: "Its the applications, stupid".

Mac OS X isn't exactly starved of good apps. Its just that developers are still forced to make a choice of platforms when developing new software, and the sensible choice is still Windows. Until that choice is removed, the choice will always be Windows. It doesn't matter if OS X has all the bells and whistles, what matters is market share and performance (I added performance because of Java).

ICC won't make a jot of difference unless its included in XCode for Windows.

Re:Short answer? No

[Anonymous Coward]

GCC doesn't vectorize for Altivec

No, but IBM's XLC/C++ did.

Re:Short answer? No

[Lars T.]

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? 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 with AltiVec (and to a lesser effect with SSE/MMX/3DNow) that can never be generated by autovectorization.

Re:Short answer? No

[TheRaven64]

Vectorisation is a lot harder with C than with FORTRAN. FORTRAN includes vector primitive types, so you don't need much skill to generate efficient code from them - just split the vectors into vector-word lengths. The sooner the world stops using a PDP-11 assembler macro language, and moves to a real language the better.

Re:Short answer? No

[gig]

The fallacy is that it's only Altivec that makes PPC worthwhile on the Mac.

The PPC architecture itself is new enough that it was designed with the idea that the computer is graphical and multimedia oriented in nature. So there are basic CPU functions for rotating graphics and doing things that video and audio rely on. PowerPC rotates bitmaps more efficientely and does other graphics manipulations more efficiently than the Intel architecture, so in turn it runs Photoshop faster and video editing is faster and Aqua is faster.

Nowadays we are getting to where the CPU's are just hugely fast in and of themselves but a few years ago this was a really big deal because it's only recently that computers are really fast enough for heavy graphics and video work. You can see this in the evolution of Aqua from sluggish on Mac OS X 10.0 to very fast now. The CPU's have caught up and the graphics processors have caught up.

If you ever see any of the old Photoshop shootouts that Apple used to do watch the PPC system pull ahead as soon as some layers of the graphic are rotated slightly or heavily transformed in size. That's what you do all day in Photoshop and the same calculations make video encoding fast.

Another big thing for PPC has been low-power chips. Even with no "portable" G5 it is still a much more sensible CPU than a Pentium4 from a power perspective and yesterday the G4 and G3 were even moreso as far as the power they draw. Five hours of battery life has been a standard on the Mac for many, many years.

So it isn't like Altivec was the only magic that made PPC worthwhile.

In this Intel transition Apple quite clearly is going for Intel's "next-generation" chips. The Centrino and the stuff that's evolving out of that are what Apple is interested in and these are Intel's most "PowerPC-like" chips with lower clock speeds, smaller size, and lower power consumption than the Pentium4. So as much as there is a win here for Intel it is not a win for yesterday's Pentium4 white box that uses 110 watts to reach 4 GHz and those of us who spent the last few years on PowerPC chips are not unhappy with the great systems we used to make graphics, video, and audio during that time.

Re:Short answer? No

[Slack3r78]

I don't disagree that PPC was very competitive at one time, and I'm disappointed to see its last semi-mainstream desktop supporter move away from it, but these aren't the Pentium II days anymore. Clock-for-clock the G5 is a little bit better than the P4, but slower than the P-M or K8, both of which draw relatively little power. The Pentium M suffers from relatively weak floating point performance (which would have an adverse effect on many multimedia operations), but has a fantastic integer unit which bests even the K8 clock-for-clock. The upswing is Yonah, the first core likely to be included in a Mac anyway, is supposed to bring marked FPU improvements to the P-M core.

Another big thing for PPC has been low-power chips. Even with no "portable" G5 it is still a much more sensible CPU than a Pentium4 from a power perspective and yesterday the G4 and G3 were even moreso as far as the power they draw.

Yes, the G5 draws less power than a Pentium 4, but the P4 is not Apple's future. The P6 core is. The fact is, the G5 just plain hasn't scaled well and the G4 is hampered by front side bus speeds that were fast 4 years ago. Yes, the chips are fast clock-for-clock, but when they fail to scale, that doesn't mean too much.

Five hours of battery life has been a standard on the Mac for many, many years.

You must not have used any of the Aluminum Powerbooks. You'll get 2.5 hours on a *good* day. iBooks have traditionally done a little better in this regard, but that's because they've also generally been packaged with slower CPUs. Most Pentium M notebooks these days get 4-6 hours of battery life while performing considerably faster than Apple's fastest Powerbook.

So it isn't like Altivec was the only magic that made PPC worthwhile.

I never said it was, merely that Altivec was highly overrated in the amount of difference it made to *most* users.

So as much as there is a win here for Intel it is not a win for yesterday's Pentium4 white box that uses 110 watts to reach 4 GHz and those of us who spent the last few years on PowerPC chips are not unhappy with the great systems we used to make graphics, video, and audio during that time.

On this we agree. The Netburst architechture has been in trouble since before Prescott's release in Jan 2004. It took AMD and the K8 essentially wiping the floor with Netburst for Intel to realize that low clock, high IPC designs like the Pentium M were the way forward.

I've posted here many times that I feel the Pentium M is the best chip to ever come out of Intel, but it's not without its weaknesses. Media perfomance on Mactels will largely depend on how much of an improvement to the FPU Yonah brings. I've heard many people hailing Yonah as Intel's savior, but I'm waiting to see it first. I would expect Intel based portables some time Q1 next year though.

Yeah, sure.

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

[Guy Harris]

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

Re:Yeah, sure.

[Anonymous Coward]

In a sensible universe, you'd think that'd be the case, but in actuality, it turns out that programs generated by the Intel compiler like to lobotomize themselves when running on AMD processors. A commonly cited example is substitution of a crippled memcpy() implementation on the generic x86 path (one of the first targets for optimization in almost any C compiler), while Intel processors use an optimized version that would run on any x86, but is only enabled on Intel processors. Heck, in some cases Intel would cripple a program if it were running even on their older generation processors, in order to embarrass the Pentium 4 less. Something as simple as forcing the value of a global variable can restore the performance. Anti-competitive? I guess the courts will decide that soon enough.

Re:Foul!

[oscast]

>"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

[harlows_monkeys]

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.

Re:No

[arkanes]

Supporting multiple compilers is harder than you'd think. Look at the code base & makefiles for pretty much *any* major cross platform project and you'll find all kinds of wierd hacks and little tweaks because such and such a compiler can't handle such and such a thing. Thats not even counting the compiler-specific extensions you might want to use for performance reasons. The state of C++ compilers has improved a lot in the last few years, but there's still a lot of older compilers (MSVC 6 being a shining example) and a lot of code to support on those compilers.

Fair!

[SteveM]

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

Re:Fair!

[tbone1]

• I know it is /., but you might want to consider reading the occational article.

Hey, we have to conform to our de facto standards!

"I must say, Headmaster, that your standards are rather out of date."
"Of course they're our of date! Standards are always out of date. That's what makes them standards."
- Alan Bennett, Forty Years On

Is that a challenge?

[PygmySurfer]

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

Re:Is that a challenge?

[Guy Harris]

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.

The Mac OS X compilers and libraries will probably require some special software, called "Mac OS X", to be running on the machine.

Re:Foul!

[harlows_monkeys]

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.

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.

Who will use this? Not me!

[Zobeid]

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.

Re:WTF?????

[exp(pi*sqrt(163))]

Apple will still be using GCC

I hope not. Based on my experience with these compilers they could probably get a 30% speed boost in OSX if they rebuilt it with the Intel compiler. 30% is not to be sniffed at.

AltiVec ona a x86 compiler?

[Squashee]

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?

Re:AltiVec ona a x86 compiler?

[brokeninside]

If Intel supported the AltiVec instructions, large swaths of code that uses AltiVec instructions wouldn't have to be changed in order to use Intel's compiler chain rather than Apple's compiler chain.

Re:AltiVec ona a x86 compiler?

[cosmic_0x526179]

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 the watt/performance bumps.

Re:AltiVec ona a x86 compiler?

[Wesley Felter]

That part of the article is just confused; it's best to just ignore it altogether.

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:AltiVec ona a x86 compiler?

[GaryPatterson]

Apple provide a page on their developer site that maps Altivec instructions to SSE instructions. It's not clean, as SSE is different to Altivec and many Altivec commands require several SSE commands each.

Intel are probably just supporting this mapping in the compiler. It may just be a preprocessor macro, or even a change to header files.

Cross-platform development started in 1996

[teutonic_leech]

Remember - a little-known language called 'Java'? ;-)

Re:Cross-platform development started in 1996

[Bastian]

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.

Re:Cross-platform development started in 1996

[Anonymous Coward]

Oh come on. What language is the JVM (and Perl, Python, etc., etc.) implemented in? C, of course. The JVM is the cross-platform app. Compiled java only runs on one platform: a JVM.

Re:Cross-platform development started in 1996

[TheRaven64]

1996? Hmm. Remember a little-known specification known as `OpenStep'? Out-of-the-box support on Solaris, Windows, OPENSTEP and, later, OS X. Now also support on any of the platforms supported by GNUstep.

Re:Cross-platform development started in 1996

[Anonymous Coward]

uhm, everyone who keeps saying "JAVA".. shush will ya..

Java is a sluggish language that runs in a virtual machine with a lot of overhead. It's only good for making slot machine games on websites.. This topic relates to real languages that are compiled to use the actual hardware in a computer, and not some silly VM.

Re:Foul!

[aristotle-dude]

Your right, it was still in Intel's favour since GGC started out on Intel and has more optimisations for it than PPC.

Using the IBM benchmark would have been even more artificial since almost nobody would have used it to do their compiles wheras many open source projects would have used GGC on both Intel and PPC.

I doubt it.

[Anonymous Coward]

"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!".

Re:I doubt it.

[Guy Harris]

But for their own builds of OSX, I would expect Apple to move towards Intels' tools.

For at least some components of OS X, they can't do that; the article says "The Intel tools will support C, C++ and FORTRAN, but will not provide a compiler for Objective C". The compilers "will be interoperable with Objective C", which presumably means "will generate C and C++ code that can be called from Objective-C code generated by Apple's GCC".

Re:I doubt it.

[btarval]

How long do you think that will last, though? I can see a really strong motivation for squeezing out the most performance here. It would certainly be a great marketing statement, and I wouldn't be surprised if such an effort was part of the deal to get Apple to switch over to Intel.

The last I had heard, you had moved over to Apple yourself, so I'd be especially interested in your opinion here.

Benchmarks

[Anonymous Coward]

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.

Re:Benchmarks

[mdarksbane]

Unfortunately, the answer to this (in most pure benchmark cases) is *not* OS X, mostly because of their messaging and thread creation routines are significantly slower, for various reasons that I'm not quite technically qualified to explain.

So while they do some nice tricks in general (and I'm still convinced that their scheduling and virtual memory systems are better, as my old laptop never bogs down because one process is taking over like my PC does) in more pure benchmarks (like SQL server max connections) they lose miserably.

Re:Who will use this? Not me!

[Wesley Felter]

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

So PPC machines get left behind

[SiliconTrip]

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.

Re:So PPC machines get left behind

[Anonymous Coward]

Why does Intel need to produce PPC binaries?

Intel is doing their side of the deal here, Apple already has PPC binaries covered with GCC (or, presumably, anything IBM may already be offering).

Apple could just as well use GCC here, but the Intel compilers probably have some sort of edge over GCC. Too lazy to RTFA to find out.

GCC?

[nurb432]

Yes, its good, but not as cross platform as something like python.

Re:WTF?????

[petermgreen]

switching compiler is not to be taken lightly either. sometimes code that works fine with one compiler won't work with another either due to bugs in the new compiler or due to bad assumptions made by the code itself.

Re:WTF?????

[Guy Harris]

However the comment that "...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..." would suggest that they will be creating universal binaries and supporting PPC

...or that the author of the article didn't know what the hell he was talking about. I would be greatly surprised to hear that Intel would devote any effort whatsoever to add support for a competitor's instruction set architecture to their compilers; I would not be surprised to hear either that Intel wasn't even asked whether they'd support Altivec, or that the question was asked of some Intel spokesperson who had no clue what "Altivec" was and who gave a canned PR-department "we haven't yet considered that" answer.

No Objective C support in ICC

[Rubel]

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.

Re:No Objective C support in ICC

[ArbitraryConstant]

A customer the size of Apple would have no trouble obtaining a source license to ICC.

Re:No Objective C support in ICC

[Anonymous Coward]

Actualy. Apple contributes not only to GCC for the PowerPC but also to the ARM back end. I would imagine this is mainly because they use ARM for their iPod. They may also use MIPS for the AirPort (just a guess) as it is based off a Broadcom chipset (and Broadcom usually uses MIPS cores).

So I agree, I think Apple has invested quite a bit in GCC. Oh well, I'm still stuck targetting an m68k board! One of GCC's original targets!

Re:Foul!

[callipygian-showsyst]

only way to level the playing field is to use the best compiler available for each processor

Exactly! You need to use the manufacturers recommended compiler on each platform. It's too bad that the folks brainwashed by Steve Jobs dishonest were quick to label my comment flamebait. I have No Idea why people would go to great lengths to defend a commercial company's hardball marketing tactics.

Re:Foul!

[Guy Harris]

because Apple could have used their own compiler and got faster results too

Apple's compiler is GCC (or, at least, GCC-based). Did you mean "IBM's compiler" (XL C/C++)?

Re:Foul!

[JFitzsimmons]

How would they use Intel tools on PPC arch?

Meanwhile...

[Anonymous Coward]

...millions of Java programmers look up, glance at the hardware changes, and get back to work.

Re:Meanwhile...

[Anonymous Coward]

... writing shitty code.

Counterfeit OSX ?

[Brad1138]

Will Mac be any more successful than MS at preventing Illegal copies of there OS?

Re:Counterfeit OSX ?

[Narcogen]

I assume they will have to become at least as good if not better. Right now, OS X has no copy protection to speak of-- not even a registration code.

Up until now, there's been no incentive for Apple to have any; anyone who can use a copy of OS X by definition owns a Mac and therefore is already a client. All Apple is losing if you pirate new copies of OS X is your upgrade purchase, which is not nearly as significant as Apple's margin on hardware.

However, I think at least to keep the majority of vanilla PC users who might otherwise have switched to an x86 Mac from using a hacked copy, Apple will have to put in some rudimentary protection schemes.

I think they'll benefit from the positive buzz surrounding the hobbyists that make OS X work on white box PCs and like what they see, but as long as the process is not too easy, it won't cost Apple hardware sales.

Despite recent advances, I don't think the market for 'counterfeit' OS copies for OS X is large enough to warrant the entry of serious counterfeiters, like the ones in Russia, China, and many other places that produce packages that look quite a bit like legitimate copies of Windows and sell them with a nod and a wink at rock-bottom prices.

I actually did see copies of OS X like that in Moscow back in 2001, but not since then.

Re:Who will use this? Not me!

[Guy Harris]

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

Why cant Intel build PPC's?

[LuckyLimey]

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.

Re:Why cant Intel build PPC's?

[Anonymous Coward]

Why would Intel be intested in fabbing a low-volume desktop chip? And, PCC's can _not_ be built by anyone.

Re:Why cant Intel build PPC's?

[TheRaven64]

Intel could build PowerPCs. Anyone can. What Intel can not do is provide enough funding to invest as much as IBM (who put PowerPC chips into anything from embedded systems to big iron) for a single customer. Similarly, they could not invest as much in PowerPC for Apple as they do in x86 for everyone else. This means that Intel PowerPC chips would be slower than Intel x86 chips and also slower than IBM PowerPC chips (you make CPUs faster by putting more money into them).

WINE

[Anonymous Coward]

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

Smalltalk (VisualWorks) did it years before

[crovira]

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 light years a head of Java's MV. They've been at it longer, is all.

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

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.

Look outside the box...

[It doesn't come easy]

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

Re:Who will use this? Not me!

[Wesley Felter]

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.

You will NEVER be able to build your own Mac...

[crovira]

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?

Re:You will NEVER be able to build your own Mac...

[Anonymous Coward]

I was under the impression they design their own memory controllers.
Namely on the G5 Powermacs.

misleading article title.

[terrox]

Yet another misleading article title.

Intel Ports Developer Tools to OS X

Re:Who will use this? Not me!

[GaryPatterson]

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.

Re:Foul!

[prockcore]

Your right, it was still in Intel's favour since GGC started out on Intel and has more optimisations for it than PPC.

No. GCC started out on VAX. It wasn't ported to intel until 1989 (after it has already been ported to MIPS and Sparc)

The focus on optimizing GCC didn't happen until recently.

The PPC optimizations in GCC are every bit as mature as the x86 optimizations. Probably even more so since there are 10 different x86 targets to optimize for, and only 2 for PPC.

Regardless, GCC has always been about correctness and portability rather than speed.

No Objective-C support

[SuperKendall]

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.

Re:No Objective-C support

[mederjo]

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.

I'm not sure most people use Cocoa to develop for OS X. A lot of people do, but I don't know that it would be half of Mac developers. Most of the important Mac apps ( at least what I consider important in my experience ) are written using Carbon.

Anyway, nothing to stop people moving performance critical code out to a library and compiling it with ICC. My own app has its Altivec code in a shared library/DLL, as that's the safest way to support machines without an Altivec unit ( G3 and earlier ).

Re:No Objective-C support

[Anonymous Coward]

Almost all Mac-only software released in the last couple of years is cocoa. I wouldn't be surprised if around 80% of mac software is cocoa, whatever the figure is it's way over half. Most of the smaller mac only apps that were carbon have also been ported to cocoa by now.

Apart from the occasional RB or Java app, it's only really the cross platform apps like Adobe CS that aren't written in Cocoa. Even a lot of cross platform apps use a cocoa front end. Also, games are hardly ever written in cocoa, even the mac only ones. Cocoa simply isn't suitable for coding games. But other than that, almost all mac software is cocoa, it's simply the best framework.

Re:No Objective-C support

[akac]

And faster games possibly since game ports are mostly Carbon/C/C++.

Re:Who will use this? Not me!

[Zobeid]

quote>

You need to remember that there won't be an AMD-based Mac, only Intel-based Macs.

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.

Re:Who will use this? Not me!

[Zobeid]

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?

Re:WTF?????

[mnemonic_]

Apple will still be using GCC.

Why, and how do you know this?

Can't wait

[wandazulu]

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.

so does this mean the death of OS9

[cvos]

will Apple finally stop supporting 9?

Re:so does this mean the death of OS9

[Anonymous Coward]

that's already happened. they're not even supporting 10.1 or 10.2 anymore.

Re:so does this mean the death of OS9

[TheRaven64]

Rosetta does not support running the Classic environment, so only OS X native apps will run on OS X86. This may well prove to be a limiting factor for some people - I only use classic for playing old games, but some people probably use it for more sensible things.

not to be a grammar nazi, BUT

[Anonymous Coward]

A quote from the blurb above:

This, as Apple is working on its first Intel-based Macs, due sometime in 2006.

This WHAT?

Grrrrr.

AC

Re:Who will use this? Not me!

[jcr]

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

Non-descript white rectangles?

[Anonymous Coward]

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*

Re:Non-descript white rectangles?

[Anonymous Coward]

Thanks for proving that you're a fucking idiot.

Except the Mac OS X PowerPC platform

[noidentity]

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.

Objective-C

[Anonymous Coward]

Intel's announcement states that they will not support Objective-C. That makes it mostly useless for 50% (guestimate) of OSX developers.

god, oh god

[Anonymous Coward]

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.

Re:Who will use this? Not me!

[GaryPatterson]

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.

Re:Who will use this? Not me!

[Anonymous Coward]

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"

[l3v1]

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

This is terrible

[iopred]

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.

Re:Foul!

[Wiz]

Not really.... the Pentium 4 is heavily dependent on vectorisation to get any sort of good performance. Such auto-vectorisation only appered in gcc 4.0, and more work on it is going into gcc 4.1.

If they had used ICC, then they'd have had this and the results would have been very different. Don't believe me? Go look at the SpecINT/FP scores for the P4 & 970 (IBM have posted some). The P4 is much much higher.

Now, if they'd used GCC and pitted it against an Opteron then they would have also lost as the Opteron is fine running "normal" code.

Re:Who will use this? Not me!

[jcr]

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

Back to reality please!

[polyp2000]

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.

Glad someone else realizes it...

[alexhmit01]

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

Re:Glad someone else realizes it...

[TheRaven64]

Microsoft also now owns a decent x86 emulator for PowerPC (VirtualPC). On code small enough to fit in the translation cache which is CPU bound, this comes close to native performance. The main bottlenecks are I/O and especially video. If they provided something like QEMU based on this - run x86 code calling PowerPC native system calls - then a PowerPC-based Windows workstation might be quite attractive. Legacy x86 apps could run at a decent speed, and native PowerPC apps could run faster. Factor in .NET, and it becomes even more plausible - if your app is in .NET bytecode calling native system functions then it could run equally well on x86 or PowerPC.

I don't know if MS will ship a version of Windows for PowerPC, but they certainly could, and if it looks like Intel are becoming too powerful then they might.

Oh come on humorless mods

[Anonymous Coward]

That was +5 FUNNY

Re:WTF?????

[Sketch]

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

Apple has released several of their own projects as OSS. What are the requirements to be "in the OSS camp", 100% open source software?

Red Hat is about as in the OSS camp as you can get, and they still ship some proprietary software in their commercial distributions (real, flash, acrobat, etc).

No problem supporting both

[mbessey]

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

Xcode can already do this...

[mbessey]

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

Re:easy!

[Anonymous Coward]

This due. Duh! :o)

Re:They sell Hardware Hardware Hardware!

[vertinox]

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.

Yellow Box

[toph42]

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.

You're in a box...

[argent]

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.

Yes, Write Once Debug Everywhere.

[Aram Fingal]

That was their motto, wasn't it?

Re:WTF?????

[A.K.A_Magnet]

Apple has released several of their own projects as OSS. What are the requirements to be "in the OSS camp", 100% open source software?

It is not about requirements, it's just that I don't view Apple (as a company, meaning Steve Jobs & directors, not employees of course) as ideologically committed to free software. They use it, release some non critical software as free if there is direct interest for them (e.g the bonjour protocol they'd like to see on more OS'es or launchd because nobody wants it ;)); They're not bad players either. They're like IBM on this matter, but recently IBM has been putting real monney for lot of devel. I'm not putting a good/bad manichean flag on companies anyway, but even if IBM was big bad, I can only thank them daily with Eclipse or improvements on the linux kernel...

RedHat on the other hand has always been committed to FOSS. Even if they ship real, flash et al, it's not their choice that it's closed. They do it to provide a better end-user experience, and it's their choice. I am using Debian and even if it doesn't come with Java, flash, ..., I installed them because I needed them. I respect both RH and Debian choice in this case. Debian choice is more ideological, and RH's more practical. However, I think all RedHat code is released under a FSF-happy license.

But hey. Even if it's great to release everything under a free software license, I don't think it would be a so-called "requirement" to be in the OSS camp. The reason why RH is in the FOSS camp is that if someday the capital was overthrown by OSS-haters, all developers would leave. They are in the FOSS camp because Alan Cox and other employees, even in the direction, are FOSS lovers. They think it is great not-only because it's great business. They started before the "Open Source" definition, before the hype. Now maybe I'm wrong but I don't think so (that's why we do have opinions hehe).

Ximian, before being brought by Novell, had several closed products. But in my view, they were still a company in the OSS camp, because they were working for the Linux community. They loved OSS. Miguel De Icaza had the FSF award for good reasons (I can thank him daily for GNOME, and Ximian for Evolution when I used it). And Novell's trying to prove us they do too, now :) (so far it's nice, who would have thought YaST would be free some day? :))

If I was to develop a video game in a game studio (not a mini linux game hehe), I would certainly liberate the source code, but I would certainly keep the artworks, graphics, music (maybe not?), as propriertary. To ensure that someone won't sell it in my place (and legally). But if someone wants to create a similar game, well it's all in the interest of the gamers (since the game is out faster), and if they improved my code, I get the improvements back (if I used a GPL-like license). They just have to create their on content. But I wouldn't shoot in my foot by releasing the whole game as free software. Now, many people on the free software camp would disagree on this, some wouldn't. But I would still view myself as a free software guy.

Ideologically, I think infrastructure software (ie: everything except what's part of the content) should be free (and free content is great too, look at Wikipedia..), and I'm sure one day everything will be free except very specialized software. Everything common will have one or more free (hey all my "free" refer to free as in speech) softwares with most of the market. We're already almost there in terms of free alternatives for everything (I don't miss anything from propriertary OS'es and I've been on Debian for years), but in 15 to 30 years, it won't be "alternatives" but everyone's obvious choice. At least that's what I foresaw in my crystal ball when I was really high ;) (but even then, I would not criticize a company for not realising OSS software, because it must be a CHOICE, and it's not the ultimate solution fo

Re:Better cross-platform development

[Anonymous Coward]

This was intended to be funny, not a troll.