Bi-Endian G4s & Windows Compatibility
First off let me state that I have limited knowledge in processor design and system architecture, but my curiosity has led me to question the possibilities of compatibility with Windows programs on OS X with limited or no emulation.
What first led me to question this is a statement made by someone on AI about the G4 being bi-endian (most of my argument is based on the validity of this and the presumption that the other endian state is little) if all of this is BS please inform me.
If the G4?s state can be altered to little endian how monumental a task would it be to program a low level framework using Windows API?s (perhaps borrowing from <a href="http://www.winehq.com/" target="_blank">WINE</a>) that works with the scheduler to switch the G4 ?s state to process Windows programs, what type of emulation would be required to allow for this. If it isn?t possible to do so, what benefit if any would Virtual PC gain if endian state could be switched?
Yes, I know it?s a pipe dream but I think it?s worth discussing.
[ 06-04-2002: Message edited by: DiscoCow ]</p>
What first led me to question this is a statement made by someone on AI about the G4 being bi-endian (most of my argument is based on the validity of this and the presumption that the other endian state is little) if all of this is BS please inform me.
If the G4?s state can be altered to little endian how monumental a task would it be to program a low level framework using Windows API?s (perhaps borrowing from <a href="http://www.winehq.com/" target="_blank">WINE</a>) that works with the scheduler to switch the G4 ?s state to process Windows programs, what type of emulation would be required to allow for this. If it isn?t possible to do so, what benefit if any would Virtual PC gain if endian state could be switched?
Yes, I know it?s a pipe dream but I think it?s worth discussing.
[ 06-04-2002: Message edited by: DiscoCow ]</p>
Comments
i looked into wine, and in their docs or faq they address making it avail on ppcs but note that it would be a very different project. its not nearly as simple, and would require a lot of emulation. as far as running a windows prog, there is also a version of linux, called `lindows`, which claims the ability, but i dont remember if they had any comments on being able to run on ppcs.
I would assume any windows emulators are taking advantage of the fact that the PPC architecture handles both formats; It'd be stupid not to.
[ 06-04-2002: Message edited by: whee ]</p>
<strong>I would assume any windows emulators are taking advantage of the fact that the PPC architecture handles both formats; It'd be stupid not to.</strong><hr></blockquote>
\tThe endianness of a PowerPC chip is set up at boot time and is immutable until the next reboot. Windows emulators are *not* able to take advantage of the little-endian behaviour of PowerPCs if running on a big-endian OS, such as MacOS X.
<strong>
\tThe endianness of a PowerPC chip is set up at boot time and is immutable until the next reboot. Windows emulators are *not* able to take advantage of the little-endian behaviour of PowerPCs if running on a big-endian OS, such as MacOS X.</strong><hr></blockquote>
The PPC architecture can handle both formats by swizzling some bytes. You can't change the mode while running, but you can handle either format. Like I said before, PCI is little-endian. If the CPU couldn't handle both modes (bi-endian) while running, there would be a major problem. Granted, it's not the 'native' mode at the moment, but it can be handled (which is what I said in the first place).
If it's easier or quicker to use little-endian for an emulator, it'll be used.
[Edit: And VirtualPC does this very thing. When emulating x86 architecture, it operates in little-endian mode. This is the very reason they dropped support for pre-G3 processors -- the operations required to do this were expensive until the G3/G4.]
[ 06-04-2002: Message edited by: whee ]</p>