everything, except Classic, can or is X86 ready. Now. Today.
The only thing Macs would really miss would be a processor with AltiVec instructions.
If Apple can collaborate and buy Moto's intellectual property of AltiVec and then add them to some co-designed processor with AMD for example... well, we got ourselves a winner.
Nonetheless, it would seem that a Power4 from IBM (coming with 64bit and a "160+ instruction vector unit (which screams altivec all over)) would be the best bet (or easiest). Then again, if we really have to look in the long term, going to an X86 architecture will be MUCH better for R&D and bottom line.
Barring the report which set off this thread (and all the "me-too" articles), there is NO valid documentation that the current Classic or Carbon, Quartz, I/O Kit, not to mention the new, upcoming technologies, have x86 code-compliant counterparts. Even the newer parts of Cocoa and WebObjects do not necessarily exist as x86 code...
<strong>Barring the report which set off this thread (and all the "me-too" articles), there is NO valid documentation that the current Classic or Carbon, Quartz, I/O Kit, not to mention the new, upcoming technologies, have x86 code-compliant counterparts. Even the newer parts of Cocoa and WebObjects do not necessarily exist as x86 code...</strong><hr></blockquote>
No evidence... that I agree with. On the other hand the fact still remains that the majorty of the code base for X WAS running in the world of x86 (only on x86 IIRC) and breaking that feature would have been a really bad thing to do since it once again would limit their choices moving forward.
I'm not one to think that we will see Apple moving to x86 any time soon but having an OS that keeps current with both the PPC world as well as the x86 world does leave 'lots of options'... Hmm now where did I hear that before.
<strong>Barring the report which set off this thread (and all the "me-too" articles), there is NO valid documentation that the current Classic or Carbon, Quartz, I/O Kit, not to mention the new, upcoming technologies, have x86 code-compliant counterparts. Even the newer parts of Cocoa and WebObjects do not necessarily exist as x86 code...
engpjp</strong><hr></blockquote>
First, I agree, it's an escape pod. It would take something really drastic (Like Mot SPS shutting down) to get used.
On the other hand, there's no good reason for anyone to expect any of the 'Cocoa' path of tools to be losing any cross platformness. The development environment is set up to hide the hardware oddities. The default 'Darwin' compile still makes a fat binary.
Also, IOKit is part of Darwin, and there's Darwin/x86 -> isn't that already done? No, not all the _drivers_ necessarily, but it is there.
And WebObjects = Distributed/Web-focused Cocoa... and it generated Java nowdays. No, Java isn't hassle-free cross-platform, but it is more than halfway there.
The Classic and Carbon layers would clearly be the big hurdle. But weren't there lots of reports (in 99 or so) that a huge percentage of the CarbonAPI are exposed in Quicktime... which is cross platform?
Comments
everything, except Classic, can or is X86 ready. Now. Today.
The only thing Macs would really miss would be a processor with AltiVec instructions.
If Apple can collaborate and buy Moto's intellectual property of AltiVec and then add them to some co-designed processor with AMD for example... well, we got ourselves a winner.
Nonetheless, it would seem that a Power4 from IBM (coming with 64bit and a "160+ instruction vector unit (which screams altivec all over)) would be the best bet (or easiest). Then again, if we really have to look in the long term, going to an X86 architecture will be MUCH better for R&D and bottom line.
Of course I don't think Apple plans on using either.
It's a last ditch backup plan, if everything else
fails use this.
engpjp
<strong>Barring the report which set off this thread (and all the "me-too" articles), there is NO valid documentation that the current Classic or Carbon, Quartz, I/O Kit, not to mention the new, upcoming technologies, have x86 code-compliant counterparts. Even the newer parts of Cocoa and WebObjects do not necessarily exist as x86 code...</strong><hr></blockquote>
No evidence... that I agree with. On the other hand the fact still remains that the majorty of the code base for X WAS running in the world of x86 (only on x86 IIRC) and breaking that feature would have been a really bad thing to do since it once again would limit their choices moving forward.
I'm not one to think that we will see Apple moving to x86 any time soon but having an OS that keeps current with both the PPC world as well as the x86 world does leave 'lots of options'... Hmm now where did I hear that before.
D
[ 09-03-2002: Message edited by: DaveGee ]</p>
<strong>Barring the report which set off this thread (and all the "me-too" articles), there is NO valid documentation that the current Classic or Carbon, Quartz, I/O Kit, not to mention the new, upcoming technologies, have x86 code-compliant counterparts. Even the newer parts of Cocoa and WebObjects do not necessarily exist as x86 code...
engpjp</strong><hr></blockquote>
First, I agree, it's an escape pod. It would take something really drastic (Like Mot SPS shutting down) to get used.
On the other hand, there's no good reason for anyone to expect any of the 'Cocoa' path of tools to be losing any cross platformness. The development environment is set up to hide the hardware oddities. The default 'Darwin' compile still makes a fat binary.
Also, IOKit is part of Darwin, and there's Darwin/x86 -> isn't that already done? No, not all the _drivers_ necessarily, but it is there.
And WebObjects = Distributed/Web-focused Cocoa... and it generated Java nowdays. No, Java isn't hassle-free cross-platform, but it is more than halfway there.
The Classic and Carbon layers would clearly be the big hurdle. But weren't there lots of reports (in 99 or so) that a huge percentage of the CarbonAPI are exposed in Quicktime... which is cross platform?