Running Snow Leopard on a PowerPC Mac

[Jubadub]

Going back a bit to the original subject of the topic (Snow Leopard and other x86 OSes on PowerMacs), I came across something the other day that may be highly relevant: HQEMU (as opposed to QEMU).

HQEMU seems to be the result of a QEMU + LLVM combination. I learnt of it through Raptor Computing (the guys behind the newly-released Talos II POWER9 system), through one of their tweets: https://twitter.com/RaptorEng/status/961188550363570176

It seems to perform much, much better than QEMU. And in principle, it indeed should, at least. Here're some videos I found, although I don't know if the host machine was ever PPC in those:

A PPC64-host-compatible version of HQEMU does exist, though, and for now I'm assuming old LLVM versions do exist for Mac OS X Tiger/Leopard that could work for HQEMU. Hopefully those assumptions are correct. I also assume that by saying "PPC64" they mean Big Endian PPC64, rather than Little Endian (which is used more and more nowadays with newer IBM processors, one reason being it facilitates porting of x86/AMD64 GNU+Linux software to POWER counterparts), meaning G5 machines should be good to go. I haven't looked much into it yet, but here's the only version that is PPC-compatible:
- Download : http://itanium.iis.sinica.edu.tw/hqemu/download.php?v=0.13.0
- Installation Guide: http://itanium.iis.sinica.edu.tw/hqemu/download/quickstart-0.13.0.pdf

Finally, the official website: http://itanium.iis.sinica.edu.tw/hqemu/

What does worry me is that it labels that version with "Process-level emulation only", which, from what it sounded like, may not yet allow us to run Snow Leopard itself, but rather programs (processes) that are otherwise x86-Mac only. The other two, newer versions of HQEMU only support x86/AMD64 processors as hosts. Not even ARM. But they are labeled with "Process-level emulation and full-system virtualization" (although only the PPC64-compatible version has the additional label saying "Client/server model is only supported in this version.", for whatever that's worth).

I haven't had the time to look into this, so I'm annoucing this here in case anyone else feels like digging up all that stuff, in the hopes someone might be interested.

 

[Lastic]

Going back a bit to the original subject of the topic (Snow Leopard and other x86 OSes on PowerMacs), I came across something the other day that may be highly relevant: HQEMU (as opposed to QEMU).

HQEMU seems to be the result of a QEMU + LLVM combination. I learnt of it through Raptor Computing (the guys behind the newly-released Talos II POWER9 system), through one of their tweets: https://twitter.com/RaptorEng/status/961188550363570176

It seems to perform much, much better than QEMU. And in principle, it indeed should, at least. Here're some videos I found, although I don't know if the host machine was ever PPC in those:

A PPC64-host-compatible version of HQEMU does exist, though, and for now I'm assuming old LLVM versions do exist for Mac OS X Tiger/Leopard that could work for HQEMU. Hopefully those assumptions are correct. I also assume that by saying "PPC64" they mean Big Endian PPC64, rather than Little Endian (which is used more and more nowadays with newer IBM processors, one reason being it facilitates porting of x86/AMD64 GNU+Linux software to POWER counterparts), meaning G5 machines should be good to go. I haven't looked much into it yet, but here's the only version that is PPC-compatible:
- Download : http://itanium.iis.sinica.edu.tw/hqemu/download.php?v=0.13.0
- Installation Guide: http://itanium.iis.sinica.edu.tw/hqemu/download/quickstart-0.13.0.pdf

Finally, the official website: http://itanium.iis.sinica.edu.tw/hqemu/

What does worry me is that it labels that version with "Process-level emulation only", which, from what it sounded like, may not yet allow us to run Snow Leopard itself, but rather programs (processes) that are otherwise x86-Mac only. The other two, newer versions of HQEMU only support x86/AMD64 processors as hosts. Not even ARM. But they are labeled with "Process-level emulation and full-system virtualization" (although only the PPC64-compatible version has the additional label saying "Client/server model is only supported in this version.", for whatever that's worth).

I haven't had the time to look into this, so I'm annoucing this here in case anyone else feels like digging up all that stuff, in the hopes someone might be interested.

Thans for this info , will have a look this evening

 

[Lastic]

So far after having to go to bed yesterday and a bit of compiling , it's no luck on OS X 10.5 on a PB G4.

I had llvm-gcc 4.2 and installed llvm 2.8 from source , but the compilation always fails because of the No Thread Local Storage support for this target ( as in the host itself ).

On later versions of QEMU tgc also produces this error.

Might try on OS X 10.5 on my G5 and also using Debian PPC on the G4 altough both already have a working qemu.

 

[Jubadub]

Thanks for doing this, so far! Actually, I'm really, REALLY looking forward to seeing your results on a G5 with OS X 10.5 (assuming you eventually do try that out), as HQEMU is stated to work only with PPC64, which would exclude the PB G4 you tried it on, but include the G5.

(As you can probably tell, I'm REALLY looking forward to all of this, from the speed at which I replied. ;D)

 

[Lastic]

@AphoticD wanna chime in and give it a whirl on your PPC Linux G5's ?

@Jubadub Don't get your hopes up , I've been down this road many times, if we get process level emulation working on a G5, one can basically run an executable or binary not Snow Leopard entirely.

 

[Jubadub]

Yes, I'm aware. Hopefully we will still squeeze something useful out of HQEMU. Getting x86 Quake 2 to run at near-native speed on a G5 through something that depends on QEMU, for instance, would kinda be like a dream come true.

I guess I'm just excitable.

 

[Lastic]

No luck on OS X 10.5 on the G5 neither, which leaves a G5 running Linux to try it on.

Actually when selecting --target-list=i386-linux-user , configure states that it needs a Linux host .

Apart from that I tried every softmmu (system emulation) , i386-darwin-user, <arch>-linux-user but they mostly fail
at Thread Local Storage which simply doesn't work .

 

[Jubadub]

Oh, now that is actually sad... I guess it'd still indeed be cool if it worked at least on G5 GNU+Linux as you say, though.

But I guess now there's not much hope to see HQEMU on an OS X host... At least I wouldn't expect to see that without a lot of (unviable?) tinkering anymore...

I wish the author of HQEMU had released the source code for potential OS X porting of the PPC64 version. Maybe he could be contacted about it?

... Oh, hey. I was just about to post, but then I found what I believe to be the source code GitHub repository, even though there's absolutely no mention of it in the official website: https://github.com/ComputerSystemLab/hqemu/tree/master/hqemu
Well, I'm not sure how helpful this really will be in practice, but I'm glad this is public!
EDIT: Unless this is just a QEMU fork without any of the HQEMU-specific implementation... Although the llvm folder within it has a copyright file as well as some other files which seem to imply otherwise. This may actually be HQEMU-specific implementation.
EDIT 2: ... Nevermind. Only now I realized the source was long available from the compacted file on the official website. D'oh! For some stupid reason, I unconsciously concluded the download file had to be binaries-only.

Also, I might just as well bring the following up: there are some papers on HQEMU, hosted on the official website, but it may be easy to miss them for some people, so here they are, more visibly, in case it could interest anyone:
(March 2012) : http://www.iis.sinica.edu.tw/papers/dyhong/18239-F.pdf (Related slideshow presentation: https://docs.google.com/file/d/0B4ABp5C1a5XHSWp2YVBOeU0tZzQ/edit ) (Posted alongside the Super Tux video I showed in an earlier post.)
(March 2014) : http://www.iis.sinica.edu.tw/papers/dyhong/18243-F.pdf
(August 2015) : http://www.iis.sinica.edu.tw/papers/dyhong/18878-F.pdf
(December 2015): http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=7384333&tag=1

I also found this paper, which was one of the many sources cited in the 2012 paper above, called "Using the LLVM Compiler Infrastructure for Optimised, Asynchronous Dynamic Translation in Qemu", which seemed particularly interesting: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.205.9064&rep=rep1&type=pdf

 

[AphoticD]

Well, I gave it a go on Ubuntu Mate on the 970mp and decided to follow the quickstart to the tee. I didn't even get through step 1 - Building the patched LLVM 2.8 from source;

Building Intrinsics.gen.tmp from Intrinsics.td
Makefile:24: recipe for target '/home/user/Desktop/llvm-2.8/build/lib/VMCore/Release/Intrinsics.gen.tmp' failed
make[1]: *** [/home/user/Desktop/llvm-2.8/build/lib/VMCore/Release/Intrinsics.gen.tmp] Illegal instruction (core dumped)
make[1]: *** Deleting file '/home/user/Desktop/llvm-2.8/build/lib/VMCore/Release/Intrinsics.gen.tmp'
make[1]: Leaving directory '/home/user/Desktop/llvm-2.8/build/lib/VMCore'
/home/user/Desktop/llvm-2.8/Makefile.rules:740: recipe for target 'all' failed
make: *** [all] Error 1

I currently have GCC 5.4.0 installed. I'll try installing GCC 4.2 next and make again.

 

[Jubadub]

I finally took a quick look at the doc (link again: http://itanium.iis.sinica.edu.tw/hqemu/download/quickstart-0.13.0.pdf ) and, disappointingly but not surprisingly, HQEMU was indeed initially designed only for GNU+Linux distros on the 3 host ISAs, and no Mac OS X, something Lastic experienced first-hand. (They stated the Linux kernel as a requirement and specifically mentioned "We use 2.6.30 and later".)

Secondly, and this bit is more relevant, although it states HQEMU to be compatible with LLVM version 2.8 and up, a grid at the end of page 2 suggests that on a PPC64 host, one can only use LLVM version 3.0, no higher or lower. (Note the asterisk indicates the recommended LLVM version. Since only version 3.0 is listed as a possibility, it inevitably becomes the recommended version for PPC64.)
I don't know what LLVM version comes with the HQEMU source (2.8, if I understood AphoticD correctly?), but we have to make sure it's version 3.0 that we end up using. However, what makes me puzzled is that they also later state "Because patching LLVM is required to work with HQEMU, you MUST build LLVM from source", which is impossible if the source indeed ships only version 2.8, unless a working code merge is done between the HQEMU LLVM source and the version 3.0 source from the LLVM website (http://releases.llvm.org/download.html#3.0 ).

Also, while the doc oddly doesn't provide as many directions for PPC64, looking at the ARM cross-compiling section, where users are guided to use an x86 machine for the ARM cross-compilation, we would need to cross-compile for PPC64 as well, and thus use an x86 machine too? Not sure. Confusing.

Lastly, amongst PPC64 host OSes, the developers only tested HQEMU on Gentoo GNU+Linux. I believe most PPC64 distros ought to work, but I figured this may still be worth bringing up, as it's an allegedly-known success path.
And correct me if I'm wrong, but when they claim the host has to be PPC64, they mean not only that the processor has to be 64-bit PPC, but the host OS ought to be 64-bit, as well, implying a 32-bit GNU+Linux distro won't work.

I currently have GCC 5.4.0 installed. I'll try installing GCC 4.2 next and make again.

That might be good! As I guess you already saw, they do recommend version 4.x above others.

 

[Larsvonhier]

Have a look at a totally different approach running Snow Leo on PPC here.

 

[swamprock]

Have a look at a totally different approach running Snow Leo on PPC here.

I've been keeping my eye on that thread. I've got a few machines that this would work on, and may have to give it a try in the near future.

 

[pc297]

I understand there are existing CPU emulators/code translators like QEMU user mode and Unicorn, but I was just reading about a technology called PowerVM Lx86 which was used commercially by IBM to run x86 (32bit) instructions on their p series POWER architecture. It was developed by the same people who licensed Rosetta to Apple.

It used instruction caching without environment emulation to allow the POWER architecture to seamlessly run Intel code. It makes me wonder if there was source code floating around the net for this for some clever individual to port to Mac/PPC.

Given it is simply the inverse of Rosetta, something like this would open up massive software options to PPC, even if it did run that bit slower.

I wonder what the current legal status of PowerVM Lx86 and its source code are currently, given that the last update is from 2011 and that it was discontinued in 2013, but given that Apple still uses Rosetta for x64 to ARM compatibility. Aren't they theoretically the same piece of intellectual property?

Also going to give PowerVM Lx86 on OpenSUSE ppc64 a try, it looks like it is possible to get it from IBM, it says a POWER5 CPU is required but who knows if it wont't work on a G5 (POWER4+AltiVec), it supports the POWER6 hypervisor (neither present on the G5 or power5), but it might require the POWER5 hypervisor

 

[barracuda156]

Well, I gave it a go on Ubuntu Mate on the 970mp and decided to follow the quickstart to the tee. I didn't even get through step 1 - Building the patched LLVM 2.8 from source;

Building Intrinsics.gen.tmp from Intrinsics.td
Makefile:24: recipe for target '/home/user/Desktop/llvm-2.8/build/lib/VMCore/Release/Intrinsics.gen.tmp' failed
make[1]: *** [/home/user/Desktop/llvm-2.8/build/lib/VMCore/Release/Intrinsics.gen.tmp] Illegal instruction (core dumped)
make[1]: *** Deleting file '/home/user/Desktop/llvm-2.8/build/lib/VMCore/Release/Intrinsics.gen.tmp'
make[1]: Leaving directory '/home/user/Desktop/llvm-2.8/build/lib/VMCore'
/home/user/Desktop/llvm-2.8/Makefile.rules:740: recipe for target 'all' failed
make: *** [all] Error 1

I currently have GCC 5.4.0 installed. I'll try installing GCC 4.2 next and make again.

LLVM is essentially broken for PPC. It won’t work.
GCC, on the other hand, builds and works all through 11.3.0 (and likely 12.0.0).

 

[pc297]

The holy grail indeed. One mention was of a demo of PowerVM Lx86 running x86 Quake 2 at near native speeds on a PowerBook G4. Which is probably only barely possible with a G5 via VirtualPC and impossible with QEMU on any PPC host.

Who knows if it's true. But it would theoretically be quite possible.

How about running Darling on top of PowerVM Lx86 to run x86 macOS apps under ppc Debian/OpenSUSE, or PowerVM Lx86 on top of Noah to run x86 Linux apps under ppc 10.5.8/10.6 🤣🤣🤣?

 

[pc297]

The holy grail indeed. One mention was of a demo of PowerVM Lx86 running x86 Quake 2 at near native speeds on a PowerBook G4. Which is probably only barely possible with a G5 via VirtualPC and impossible with QEMU on any PPC host.

Who knows if it's true. But it would theoretically be quite possible.

If it's true it would mean that there was a ppc32 version of PowerVM-LX86/QuickTransit (only the ppc64 version is available). It is likely referring to QuickTransit though, as they had e.g. x86-64-> ppc64 ("QuickTransit Opteron") and x86 -> ppc32 ("QuickTransit for x86" - from which Rosetta is very likely derived)

Transitive Corporation: Solutions

If anyone has a copy of the x86 -> ppc32 version, it would be great for G4 macs under Linux currently it only works with POWER/5/6/7/G5s under Linux as only the ppc64 version is available

https://www.andrafarm.co.id/IT/en/2991-2888/Comparison-of-platform-virtual-machines_4920_andrafarm.html

Btw looking at some tutorials for QuickTransit, it is virtually identical to PowerVM-LX86 - at least the installer script offers the exact same installation options (i.e. " 1. Install QuickTransit Licensing. 2. Install QuickTransit-SPARC + SolarisWorld. 3. Go back to the Main Menu. 4. Quit." - replace QuickTransit by "powervm-lx86-1.4.0.0-1" and "Solaris" by "x86")

[QuickTransit] QuickTransitインストール手順 - Life with IT

山好きITエンジニア 木檜(こぐれ)和明 による発信の場

l-w-i.net

The very fact that there were separate versions that could run either Linux or Solaris binaries (POWER/x86/x86-64 and SPARC on the other hand) and that it is actually host-os-less (plus the fact that Rosetta relies on universal binaries) does hint at the possibility to make a custom "x86 world" for ppc if we could one day port or object convert PowerVM-LX86 from ELF ppc64 to Mach-O ppc64- so far objconv is only available for i386/x86-64/arm64 in macports but @sasho648 is making great strides towards porting it to ppc32 already - so getting the ppc32 version of QuickTransit would be great!

Last factoid: apparently QuickTransit was called "Dynamite" not only at the University of Manchester where it was developed but also at Transitice Corp, I guess they figured the name QuickTransit would sell better:

Products Overview

 

[pc297]

If it's true it would mean that there was a ppc32 version of PowerVM-LX86/QuickTransit (only the ppc64 version is available). It is likely referring to QuickTransit though, as they had e.g. x86-64-> ppc64 ("QuickTransit Opteron") and x86 -> ppc32 ("QuickTransit for x86" - from which Rosetta is very likely derived)

Transitive Corporation: Solutions

If anyone has a copy of the x86 -> ppc32 version, it would be great for G4 macs under Linux currently it only works with POWER/5/6/7/G5s under Linux as only the ppc64 version is available

https://www.andrafarm.co.id/IT/en/2991-2888/Comparison-of-platform-virtual-machines_4920_andrafarm.html

Btw looking at some tutorials for QuickTransit, it is virtually identical to PowerVM-LX86 - at least the installer script offers the exact same installation options (i.e. " 1. Install QuickTransit Licensing. 2. Install QuickTransit-SPARC + SolarisWorld. 3. Go back to the Main Menu. 4. Quit." - replace QuickTransit by "powervm-lx86-1.4.0.0-1" and "Solaris" by "x86")

[QuickTransit] QuickTransitインストール手順 - Life with IT

山好きITエンジニア 木檜(こぐれ)和明 による発信の場

l-w-i.net

The very fact that there were separate versions that could run either Linux or Solaris binaries (POWER/x86/x86-64 and SPARC on the other hand) and that it is actually host-os-less (plus the fact that Rosetta relies on universal binaries) does hint at the possibility to make a custom "x86 world" for ppc if we could one day port or object convert PowerVM-LX86 from ELF ppc64 to Mach-O ppc64- so far objconv is only available for i386/x86-64/arm64 in macports but @sasho648 is making great strides towards porting it to ppc32 already - so getting the ppc32 version of QuickTransit would be great!

Last factoid: apparently QuickTransit was called "Dynamite" not only at the University of Manchester where it was developed but also at Transitice Corp, I guess they figured the name QuickTransit would sell better:

Products Overview

Follow up: so with a bit of hacking I did get PowerVM-LX86 to work and run some x86 ELF binaries on the G5s on OpenSUSE Tumbleweed (that's the closest I could get to ppc64 SLES9-11/RHEL5-6, for which I simply could not find any isos). Command-line stuff so far as the installation is incomplete, there is no x11 stuff in it so far, but it might be possible to manually install it with the x86 version of rpm in the /i386 path.

OpenSUSE Tumbleweed

So for those running OpenSUSE Tumbleweed on G5s who are also interested in running x86 Linux software on it, I can confirm that PowerVM-LX86 seems functional on G5s under ppc64 OpenSUSE Tumbleweed. I could only do a partial install though so far (the result of which looks like a minimal base...

forums.macrumors.com

Obviously a long way off from making a reverse Rosetta to run intel SL stuff, but if somehow the ppc64 ELF binaries could be object-converted to ppc64 Mach-O it might a step in that direction.

Apart from that major hurdle some other limitations that would need to be overcome entail, among other things, the issue that PowerVM-LX86 can only "see" stuff in the /i386 directory (obviously Rosetta which is derived from QuickTransit, like PowerVM-LX86, does not have this limitation), but Rosetta uses fat system binaries in /bin, /usr/bin, /sbin, /bin, /System, /Library etc in 10.4-10.6 and can run anything ppc anywhere in /; one would need to see how this is achieved in Rosetta. The PowerVM-LX86 installer does have the option of having /home directories accessible, so it might just be an environment variable issue to solve.

Some other major hurdles involve not only having to object-convert the powervm-lx86 ppc64 ELF binaries to ppc64 Mach-o (which in itself would be a major feat, as so far @sasho648 has part of the ppc32 version working but not yet the 16-bit ha/lo relocations, but it's already great progress as objconv was originally meant only for i386/x86-64 binaries) but also to link it properly which entails object-converting and linking all the missing libraries/binaries required, notably of the Advance Toolchain (version 2.1.2, aka "at05"). There's obviously the whole question about the legality of all this, which is an entirely different ballpark altogether. I don't know how much object-converting amounts to disassembling/decompiling legally. And obviously one would need to determine how Rosetta is invoked on intel macs and reproduce this on ppc and what makes the Finder cross out Intel apps on ppc 10.4/5/10A190 (even though, as far as 10.5 and 10A190 are concerned, the Intel and ppc versions are identical and can be used on either platform, which is not the case for 10.4). In other words, how to integrate it in 10.4/10.5/10A190 as Rosetta is under Intel.

 

[pc297]

Apparently original Xbox 1 backwards compatibility on the Xbox 360 was achieved ... via QuickTransit, a.k.a PowerVM-LX86/Rosetta! I didn't know!

Xbox 2 soportará juegos de Xbox gracias a un emulador llamado QuickTransit en Retro y descatalogado › Xbox › General

Xbox 2 soportará juegos de Xbox gracias a un emulador llamado QuickTransit en Retro y descatalogado › Xbox › General

www.elotrolado.net

(Title in Spanish but the post is almost entirely in English, Wikipedia also quotes when referring to backwards compatibility on the Xbox 360)

Further to PowerVM-LX86, I will try the original QuickTransit version (I've located a build for SLES9) and let you know, but if it can achieve such performance on the Xenon, a POWER4 derivative highly related to the G5, then we should be able to achieve this too on the G5 under Linux (to start with)! And after all, Xbox 360 software and games were developed on G5s to begin with via the Xbox 360 dev kit, I don't know if the original dev kit could run original Xbox games, but it sounds likely and it also sounds likely that x86 dynamic translation via QuickTransit/PowerVM-LX86 should be working not only on POWER5-7 but also on the G5 at a sizeable fraction of native speed if configured properly. Does anyone have an original Xbox 360 dev kit left (or custom-made from a DP G5, I hear that it has been done, but it has to be the exact same model as the dev kit and have the exact same GPU for the dev kit to install) to confirm backwards compatibility on those?

Since it runs i586 Xbox games fine on the Xenon, this answers any concern that I had about the MSR endianness switch bit and hypervisor both being absent from the G5 (as opposed to POWER5-7) as it is also the case for the big endian-only Xenon/Cell.