Uli's Web Site
Apple/Intel and 64-bit CPUs
I've been holding back with any blog postings on the Intel switch because I'm not much of a hardware guy, and because I didn't really have anything to add that John Gruber or other folks much smarter than me hadn't said already. But today I read something on a German news site which I thought could add to the discussion, and while I'm covering that for the English-speaking parts of the web, I might as well add a few other thoughts that didn't merit their own posts.
According to Mac news sites' reports, the ADP2.1 employs a Pentium 4 660, i.e. a CPU with a 3.6 GHz clock rate, 2MByte L2-Cache and EMT64T/x64-support.
While EMT64T may not be a full-blown 64-bit address space (if you click the term at the bottom of the article, the definition will tell you it uses "only" 50 bits), it definitely allows for addressing loads of memory. And while I have no proof, I doubt Apple will use any lower-end CPUs for its low-end systems when they move to Intel. After all, the "Apple Development Platform 2.1" systems are being shipped to developers to aid them in developing for all of the future systems, not just for the high end.
In addition, a lot will have changed in the one year until the first Intel-Macs ship, and Intel will probably give Apple some of its scheduled new 64-bit CPUs for the high-end. It's a very plausible idea (that, again, others have had before me) that this is why Apple has asked for so much time. Even ignoring that Mathematica is a cross-platform product that already shipped for Windows and Mac (and thus had no issues with endian-ness), I've heard from many developers that switching to Intel is fairly easy.
Let me back that up with details: From what I've heard, there's the usual twiddles needed when running with new versions of Xcode and GCC, but nothing we haven't had to work through when we switched from Project Builder to Xcode, or from GCC 2.95.something to 3.x. Add to that the time it'll take for users to actually adopt IntelMacs in any significant numbers, and most developers will twiddle their thumbs half the time. Adobe and Quark also have cross-platform codebases, so the time many others will use to endian-proof their code, they'll be able to use to move off CodeWarrior, if they haven't already. Carbon is still fully supported on IntelMacs (even though some news sites will probably never get the difference between CodeWarrior, Carbon, Classic, Xcode and Cocoa...), it's just that it doesn't endian-swap for you, like most Cocoa APIs will.
So, Apple may not be waiting for the developers. They're simply waiting for Intel. And since matters with Intel got to a state where too many people needed to know about them, they just decided to announce it now, while they can live off the iPod (though, all things considered...), should sales for Macs tank.
Which is another thing I needed John Gruber to remind me of: People who buy a Mac do so because they want a Mac. Because they need a tool that fulfills their current needs. Nobody in their right mind would spend money on a Mac if a PC would do just fine for them. Ergo, those people who need a new Mac now will buy one. Intel on the horizon or not. There are no other options. Only people who don't really need a new Mac right now will be tempted to hold back. And maybe Apple will lose one more University that is looking for a Unix cluster. Boo-hoo.
The only thing I'm worried about is how many users will end up being annoyed, when, in one year or so, Adobe announces the paid upgrade to InDesign that adds Universal binaries... users don't like being forced to buy new software for their new computer. They usually just copy over their old apps and keep working with them. Mac users even more so (heck, I still have a copy of ClarisDraw on my Mac for those emergency cases). But that's what Rosetta is for, which will also be one year more mature by then.
My point? Even though it doesn't bode well that Apple had to oust IBM, they aren't up to hock in their eyebrows. Breathe deeply. Anything else is just a waste of energy.
Created: 2005-06-28 @848 Last change: 2005-06-28 @892 | Home | Admin | Edit|
© Copyright 2003-2022 by M. Uli Kusterer, all rights reserved.