How Apple can move to Intel

CNet reported that Apple is going to switch to Intel for its CPU supplier. Some people thinks that this means Intel will produce PowerPC compatible processor, but I strongly doubt it. Some other people thinks that this would involve mostly emulation of PowerPC on x86. However, I have slightly different take on this - I think Apple is going to use FAT binary to smooth the transition.

NeXTSTEP used to support FAT binary for four architectures - Motorola 68k, Intel x86, HP PA and Sun SPARC (NIHS). And it worked pretty well. Gcc compiler for NeXTSTEP had an option to produce objects for all four targets at the same time, and linker and runtime loader all supported this very well. A single executable file can contain object codes for four different architectures, and many applications were distributed for all four (NIHS), or at least for 68k and x86 (NI).

Assuming Apple didn't remove FAT support in MacOS X, it would be fairly easy for Apple to provide developers ways to create executables for both targets (a simple recompilation for both target would work for most applications, just like moving applications from Solaris SPARC to Solaris x86) and the ISVs can distribute one software package that supports both platforms.

Of course, Apple may still need to provide a PowerPC emulation for x86. But that shouldn't be too difficult either, since underlying OS and APIs remain the same. But emulation doesn't address the actual transition of ISV code itself, and it alone doesn't really ease the transition for ISVs like FAT binary does. So all in all, I bet Apple will revive FAT binary in OS X. Maybe it's time for Sun to push SPARC support in OS X...after all, Niagara and ROCK will be quite attractive as a CPU for Xserve :)

Comments:

I read that Apple used emulation to deal with the migration from 68k-based processors to the current PowerPC processors. I they still have people around who are familiar with that transistion, then perhaps they will use the same approach again. With fat binaries, there is no way to make an old piece of software work on a new system. So these two approaches really solve two different problems. Fat binaries solves the problem of packaging and distributing multiple different kinds of binaries. You have one box of software instead of 2 boxes. In a highly networked environment, fat binaries make sense so that one NFS installation of software can serve multiple kinds of clients machines on the network. Also the problem is worse with 4 supported architectures than it is with two. So something that might have made sense for NextSTEP might not make sense for Apple.

Posted by Chris Q on June 06, 2005 at 01:48 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

seongbae

Search

Archives
« March 2015
SunMonTueWedThuFriSat
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
    
       
Today