[quote]If the Mac is practically a PC (hardware-wise), Apple's going to be under immediate, constant pressure to make OS X run Windows applications.<hr></blockquote>
To make OS X run Windows applications, they would have to license or reverse engineer the Win32 API, twiddling with it and the OS X kernel so that it will run Windows apps out of the box. Apple would also likely have their own motherboard designs and chipsets, meaning that standard Windows drivers and other low level bits of the system wouldn't always work. The biggest thing is, Apple doesn't have to do Windows if it doesn't want to, regardless of proximity to the x86 design. They have been under such pressure for years and have dealt with it.
[ 03-14-2002: Message edited by: Mac The Fork ]</p>
<strong>There's one thing you guys are overlooking when you talk about emulating a PPC on x86-- PPC has FAR more registers than x86 does (what is it-- 32 vs. 14?)</strong><hr></blockquote>
The x86 ISA has 8 32bit general purpose / integer registers, 8 80bit floating point registers (accessed in stack fashion), 8 64bit MM registers for MMX and 3Dnow! which are physically the same as the FP registers (i.e. you can't use FP(0) and MM0 at once), and 8 128bit XMM registers for SSE(2).
The PPC ISA on the other hand has 32 32bit GP registers, 32 64bit FP registers (flat), and 32 128bit vector registers for AltiVec.
[quote]<strong>
That's going to cause an incredible performance hit for PPC code running on an x86 processor every time you have to swap registers in and out of memory.
</strong><hr></blockquote>
Well, in the case of high-level languages, the compiler takes care of this automatically by scheduling registers appropriately (and using memory operands instead).
And in the case of Assembler, the whole code would have to be rewritten anyway.
EDIT: Of course, my answer only applies in the case of porting. For emulation, which is what you were actually talking about, your point is of course completely valid. Sorry for my temporary confusion.
[quote]<strong>Going from 68k to PPC didn't have this problem, because the PPC has more registers than 68k did (32 vs. 16 in that case).
</strong><hr></blockquote>
Actually, there's another major reason: It's a lot easier to emulate a CISC isa on a RISC architecture than it is the other way around.
This is because most CISC operations perform the function of several RISC ops at once. Thus, you can easily find one or more sequences of RISC ops that, grouped up, each perform the same function as any given CISC op. Obviously, you can easily translate from CISC to RISC by replacing the individual CISC ops by exactly one corresponding sequence of RISC ops each.
Now if you want to go the other way around, it obviously get's complicated, becuase now the translator can't just look at the individual instructions, but has to find groups of them in the instruction stream that represent one CISC instruction each, which is a lot more complicated. In the worst case, there might even be some RISC instructions (or small groups of them) that don't have a directly functionally equivalent CISC instruction at all. Like, the RISC op does "A", and the closest thing in the CISC ISA in question is a single op that does "A", "B" and then "C". Now, by using suitable operands, you can make the CISC op have the same result as the RISC one, but it still takes longer to execute.
<strong>Yellow box is a bad idea. That's how OS/2 got canned. Why write macOS Apps if Windows apps work in OS X anyways.</strong><hr></blockquote>
I disagree. OS/2 was canned because it already ran windows on the same hardware. Likewise, developers had no incentive to write both an OS/2 and a Windows version of the same program for the same hardware. The OS/2 users could use the Windows version and all was fine. Basically, OS/2 (IBM) had no way of making developers code separately for their system.
The idea behind Yellow Box on Intel is basically to put the Cocoa API's running as a peer to Win32 APIs, just like Cocoa is a peer to Carbon on OS X. In this way, developers could code for one single API, then compile separately for each destination machine. The Yellowbox apps would like regular Windows apps and the Cocoa apps would look like regular OS X apps.
This is great in theory, but there are two main reasons why this wouldn't work.
1) You can be sure MS wouldn't like this idea and would make it very difficult for Apple to achieve this from a technical objective. For performance, they'ed need access to low level stuff in Windows. Otherwise, Apple could try to remap Yellowbox (cocoa) apis to existing Win32 stuff, but there would be a performance hit if they did that.
2) An even bigger road block would the the software developers themselves. As much as this would make life better for them in the long run, in the short run, it would mean a total re-write of their HUGE applications! If Apple can't get current Mac developers to code for Cocoa (instead, most use Carbon), how are they going to convince Windows developers to switch?
Comments
To make OS X run Windows applications, they would have to license or reverse engineer the Win32 API, twiddling with it and the OS X kernel so that it will run Windows apps out of the box. Apple would also likely have their own motherboard designs and chipsets, meaning that standard Windows drivers and other low level bits of the system wouldn't always work. The biggest thing is, Apple doesn't have to do Windows if it doesn't want to, regardless of proximity to the x86 design. They have been under such pressure for years and have dealt with it.
[ 03-14-2002: Message edited by: Mac The Fork ]</p>
<strong>There's one thing you guys are overlooking when you talk about emulating a PPC on x86-- PPC has FAR more registers than x86 does (what is it-- 32 vs. 14?)</strong><hr></blockquote>
The x86 ISA has 8 32bit general purpose / integer registers, 8 80bit floating point registers (accessed in stack fashion), 8 64bit MM registers for MMX and 3Dnow! which are physically the same as the FP registers (i.e. you can't use FP(0) and MM0 at once), and 8 128bit XMM registers for SSE(2).
The PPC ISA on the other hand has 32 32bit GP registers, 32 64bit FP registers (flat), and 32 128bit vector registers for AltiVec.
[quote]<strong>
That's going to cause an incredible performance hit for PPC code running on an x86 processor every time you have to swap registers in and out of memory.
</strong><hr></blockquote>
Well, in the case of high-level languages, the compiler takes care of this automatically by scheduling registers appropriately (and using memory operands instead).
And in the case of Assembler, the whole code would have to be rewritten anyway.
EDIT: Of course, my answer only applies in the case of porting. For emulation, which is what you were actually talking about, your point is of course completely valid. Sorry for my temporary confusion.
[quote]<strong>Going from 68k to PPC didn't have this problem, because the PPC has more registers than 68k did (32 vs. 16 in that case).
</strong><hr></blockquote>
Actually, there's another major reason: It's a lot easier to emulate a CISC isa on a RISC architecture than it is the other way around.
This is because most CISC operations perform the function of several RISC ops at once. Thus, you can easily find one or more sequences of RISC ops that, grouped up, each perform the same function as any given CISC op. Obviously, you can easily translate from CISC to RISC by replacing the individual CISC ops by exactly one corresponding sequence of RISC ops each.
Now if you want to go the other way around, it obviously get's complicated, becuase now the translator can't just look at the individual instructions, but has to find groups of them in the instruction stream that represent one CISC instruction each, which is a lot more complicated. In the worst case, there might even be some RISC instructions (or small groups of them) that don't have a directly functionally equivalent CISC instruction at all. Like, the RISC op does "A", and the closest thing in the CISC ISA in question is a single op that does "A", "B" and then "C". Now, by using suitable operands, you can make the CISC op have the same result as the RISC one, but it still takes longer to execute.
Bye,
RazzFazz
[ 03-15-2002: Message edited by: RazzFazz ]</p>
<strong>Yellow box is a bad idea. That's how OS/2 got canned. Why write macOS Apps if Windows apps work in OS X anyways.</strong><hr></blockquote>
I disagree. OS/2 was canned because it already ran windows on the same hardware. Likewise, developers had no incentive to write both an OS/2 and a Windows version of the same program for the same hardware. The OS/2 users could use the Windows version and all was fine. Basically, OS/2 (IBM) had no way of making developers code separately for their system.
The idea behind Yellow Box on Intel is basically to put the Cocoa API's running as a peer to Win32 APIs, just like Cocoa is a peer to Carbon on OS X. In this way, developers could code for one single API, then compile separately for each destination machine. The Yellowbox apps would like regular Windows apps and the Cocoa apps would look like regular OS X apps.
This is great in theory, but there are two main reasons why this wouldn't work.
1) You can be sure MS wouldn't like this idea and would make it very difficult for Apple to achieve this from a technical objective. For performance, they'ed need access to low level stuff in Windows. Otherwise, Apple could try to remap Yellowbox (cocoa) apis to existing Win32 stuff, but there would be a performance hit if they did that.
2) An even bigger road block would the the software developers themselves. As much as this would make life better for them in the long run, in the short run, it would mean a total re-write of their HUGE applications! If Apple can't get current Mac developers to code for Cocoa (instead, most use Carbon), how are they going to convince Windows developers to switch?
Steve