How would a move to x86 would effect current users?

I'm sure it would be possible to lower the Power4/5 in price and Mac OS X could be easily converted to it. plus its fast and great. and If apple buys AltiVec, we could have Power4 powermacs with velocity engines running OS X. just think of it... ah...:)
 
Originally posted by xaqintosh
I'm sure it would be possible to lower the Power4/5 in price and Mac OS X could be easily converted to it. plus its fast and great. and If apple buys AltiVec, we could have Power4 powermacs with velocity engines running OS X. just think of it... ah...:)
Click to expand...

If it was so easy to lower the manufacturing costs of CPUs, we'd probably have G5s already.

The Power4 CPU is intended for $200,000 IBM servers. We're dreaming if we honestly believe we will ever be posting to macosx.com on one running OS X.

I'm sorry to break the news to everybody but it's just not going to happen. :(
 
Originally posted by fryke


Nope, SimX. While you're right that we'd lose the AltiVec engine, there are other Multimedia Instruction Sets available on those processors. And I was also not talking about the current crop of processors but their next generations. I'm sure if Apple told AMD it would switch to them, AMD would work together with Apple for the next generation of 64bit processors, too.

And about Cocoa: It was running on X86 even BEFORE it was ported to the PowerPC platform. Cocoa was YellowBox was OpenStep's Objective C APIs was NeXT-Step's Objective C APIs. And - as we all know, there was NeXT-Step 486 and later OpenStep for the PC platform. And, of course, Rhaspody DR 1 and DR 2 were available for PC, too.
Click to expand...

First off, the SIMD instruction set implemented in the x86 world is vastly inferior when compared to PPC. Why is this? Well, it's because Intel and company are too obsessed with backward compatibility and cost of wafers. The SIMD instruction sets in x86 chips are coupled on top of the math coprocessors. They are not dedicated allocations of the chip as in PPC. What does this mean? Well, it means that the vector instructions cannot computed in conjunction to the math coprocessor (it's in the same place on the chip remember?). On top of that, the math coprocessors on the Pentiums required a "fail over" state from the integer unit before it would kick in. This means, to access the vector unit, the program first fails at the integer processor, the instruction gets kicked to the math coprocessor, fails again, then gets kicked to the SIMD unit. VERY inefficient, and VERY crappy. Yes, the x86 world has the vector processing features in name, but it's not close to the elegance and efficient enjoyed in the PPC world.

Secondly, Cocoa apps can run on both Intel and PPC platforms, but the Cocoa apps DO NEED TO BE RECOMPILED!!! When it's OpenStep, apps that can run on both the Intel and Motorola OS needed to be compiled to do so. These were called "fat binary" files. In addition, you can compile OS apps to be Intel or Motorola specific. So even though we can load the Cocoa environment on Intel, the apps still needs to be recompiled before we run them. Theoretically this should be simple, but in implementation, who knows?
 
But AFAIK all major commercial applications today like all Adobe and Macromedia products are Carbon - so Carbon also have to be ported to x86 to run - or could the entire Carbon enviroment ported and the applications stay untouched? :confused:
 
You must log in or register to reply here.
Back
Top