| Wednesday, August 7, 2002 |
14:17 - Mountains out of ...mooooooooles
http://www.zdnet.com/anchordesk/stories/story/0,10738,2876696,00.html
|
(top)  |
David, David, David.
This is a perfect example of an entire industry's press field finding completely non-newsworthy things to write about, presumably because there's nothing else on the radar. David Coursey is the latest high-profile tech columnist to leap onto the "Macs on Intel" bandwagon, which (you may recall) is founded upon nothing more concrete or explicit than Steve Jobs responding to a question about putting Intel CPUs into Macs with the line, "First we have to finish the transition to OS X. Then we'll be able to evaluate our options." That's it. That's all he said.
And now we have analysts like Andrew Neff of Bear Stearns saying that there is "an 80% chance" of Apple moving to Intel processors. Like it's some kind of weather forecast or earthquake prediction. Just what precisely are your indicators, Andrew? Did four out of five informants within Apple tell you that this was so? Or did you just wake up one morning and with a gasp of surprise find that number wedged up your rectum?
Moving to Intel CPUs, even if we cast it in such terms as "AMD would be the supplier" and "Just the CPUs and the basic architecture would change-- it would still be a whole-widget operation, and you wouldn't be able to run Mac OS X on random off-the-shelf PC hardware", would still be an intractable feat. This isn't just a matter of flipping a compile-time switch when building the OS. All the third-party application makers would have to rewrite their apps for Intel, and this would come hard on the heels of their being yanked through the (somewhat painful) OS X transition process. App developers aren't going to stand for that twice in a row. They'll throw up their hands and say it's not worth it.
And even if they didn't, even if they stuck with the Mac-- it's not just a matter of flipping a compile-time switch in those apps, either. Most of them are written in Carbon, not Cocoa-- which means there's a significant amount of 68000-based code in it. That kind of stuff would have to be rewritten from scratch, in what would be an even more painful process than Carbonizing an app for OS X. And what of little/big-endian-ness? The Intel architecture is little-endian, whereas the 68K and PPC chips are big-endian (actually it's settable at boot time, interestingly). The Mac OS has always been big-endian. What that means is that any applications which expect to read the bit order in a certain sequence would be completely screwed, and the ordering code would have to be rewritten. This applies to nearly all networking applications, just for starters.
Sure, Apple could just emulate PPC code on Intel CPUs, like they did when they jumped from 68K to PPC. But that jump was a tiny curb compared to what this undertaking would be. The PPC had a very similar instruction set and architecture to the 68K-series. It was mostly trivial. Most basic assumptions about the chip were the same. And yet the emulated code was still terribly slow; it took years to get it all ironed out and made native. None of those architectural similarities would be there for the leap to Intel; it would be a much more difficult job to write an effective emulation layer. And it would undoubtedly be even more hideously slow than the earlier transition was.
And finally, what kind of Intel chips are we talking about here? Pentium 4s? The chip that even Intel is trying to replace at this very moment-- the one that's hurtling toward end-of-life, not just for its model, but for its entire bloodline? Apple would be arriving on the x86 platform just as it reached the twilight of its twenty-year lifespan; we'd be opening the door just as the lights went out, and Intel would have moved on to the 64-bit Itanium (or Mauritanium, or Lusitanium, or whatever the new one is called-- the one that runs at 800MHz, clocked slower than the G4). Apple would once again be a laughingstock, and this time the Megahertz Myth could be used against them.
Kris says that he is willing to wager, one year from now, an Intel-based Power Mac against David Coursey's PPC-based Power Mac: if Apple is on Intel in a year's time, he'll buy one for David. If they haven't, David has to buy him one of whatever they have.
I fully agree. Apple has options here, and that's what Jobs said. He didn't say a word about Intel. (What we do see are indicators that IBM will figure prominently in Apple's CPU-supplier future, with PPC/POWER4 hybrids, an uber-G3 clocked super-high but sans Altivec (one source I read recently blames none other than Altivec for hampering the speed-ramping capacity of the G4-- it's apparently a big roadblock to increased clock speed), or even the true and fabled 64-bit "Book E" G5.)
Options. That's all they are. Not the biggest tech news of the day.
UPDATE: Within about 13 seconds of my posting this, reader Kurt Revis responds with the following to my comment about app developers not being able to compile for Intel because of legacy 68K code:
I'm sorry, but this is just wrong. Nobody is shipping Carbon apps for OS X with any 68k code, because 68k code no longer works in OS X native apps. (It still works in Classic, of course.)
For many apps (Carbon or Cocoa is irrelevant), it really *should* be a matter of flipping a switch to compile on x86 (or whatever other processor you like). Some apps which use their own PowerPC assembly code will need to rewrite those parts for the new processor, but that's generally a very small amount of code. And many apps (the vast majority) don't have any assembly code at all.
You point out that there may be some bad assumptions about endianness issues when reading from disk/network, or alignment issues in memory, but again these are not huge stumbling blocks (unless the code is REALLY bad). The best practices these days include macros to do byteswapping when reading from disk/network, as appropriate -- the macros do nothing on big-endian machines but swap bytes on little-endian ones, or vice versa.
I'm sure that these issues will affect some people, but it's hardly the end of the world. If the benefits of switching to a new processor architecture are high enough--like making your app run twice as fast--people will do the work. The PPC emulation issue is really the hard part; everything else you mention is trivial in comparison.
This is all more information for me to assimilate into what's admittedly a rather sketchy understanding in my mind of what constitutes software design issues in today's Mac world. It's all a big jigsaw, and I don't pretend to have all the pieces. After having added these, the picture is a bit clearer.
I still tend to think there are other options Apple would choose before Intel, though. And I still think app developers wouldn't stand for having to modify their code again so soon after painfully Carbonizing everything (and having to sell it yet again).
|
|
