So - for the last few months I have been meaning to get to this, but finally started to look at it over the last week.
For those that don’t know, Retro68 is a project that brings a modern GCC cross compiler that targets legacy Mac Systems, including PowerPC. The compiler will build PEF executables by generating an XCOFF exe that is then converted to PEF with the MakePef tool and can import PEF libraries and link to them through stubs that are created with another tool called “MakeImport”.
So, I knew it would be possible with work to make this all work for BeOS PowerPC becaue I have used the Mac version of the Metrowerks compilers to build BeOS apps before. So, for at the very least, basic C calls like those in libroot.so it is feasible.
I have been working with the author, Wolfgang Thaller of Retro68. You can see the dev log here. He has kindly made a BeOS branch and has altered the MakeImport tool to accept BeOS style PEF libraries.
Still early days, but today I successfully built a simple command line app that links with libroot.so and can execute puts(..). This is significant, as it proves that with work, the full standard C functionality will be possible. Hopefully a cross compiler will be able to be made and we will be in a good place to port modern code to BeOS PowerPC.
Hurdles still to jump:
we currently don’t execute main(..), we are going to the initial ‘__start()’ function. This will need to be resolved to make standard C compile.
the MakeImport works for exported C functions, but there are a few quirks… nothing that can’t be fixed. But we will need to find a solution for the C++ side of things.
BeOS does a lot of extra start-up that seems to be from the MetroWerks codebase… we need to work out if we need any/all of it. I was surprised the basic app I wrote worked, so there is doubtless more to it I don’t yet know about.
I’ll post more progress as it happens, but this is a passion project and so it will probably be slow going till I can compile more modern real world code.
If anyone want to jump in, feel free to join the fun.
When we get to the point where we can build C, yeah I think anything that is C based. The C++ is more difficult because the name mangling scheme will not match. But because we create the library imports, I guess we can probably create something like a bridge layer? I remember making it work with the Fred Fish GCC port, but that relied on using the Metrowerks linker, so this is slightly different.
Cool! I had a Retro68 checkout laying around for years without touching it, but didn’t really think about BeOS compatibility. Makes me want to code a real BeOS demo again for the BeBox
Yes there are several CRT files in BeOS, for dynamic libraries and apps… Some code was published for libroot (because it contains glibc) that has those object files and possibly other interesting stuff. And you should be able to relink libroot with other stuff inside too.
Not as a Haiku runtime, but maybe backport some of it to get more modern code to still compile for BeOS maybe…
QEMU-user is meant to translate at syscall level, but Haiku doesn’t exactly have the same syscalls BeOS had. It’d be quite a lot of work to do, and it wouldn’t translate things like app_server protocol which is also different in Haiku…
Yeah - this is a long term dream - modern compiler for PowerPC. I guess it would be nice to make more modern shell tools on BeOS PowerPC, SSH and GIT would be amazing…
I was really surprised that I could link to libroot and call a function without anything much else. I wonder how much of that is to do with the error we always get about the symbols in the two object files we always link for PowerPC already being defined when linking under R5?!
I guess I need to find a way to get all the start-up/CRT code for PowerPC now. I know it was all based on the Metrowerks runtime, so I’ll have a look around the various Mac versions of the CodeWarrior compiler I have to see if they ever released any of it.
We can recompile Haiku libraries (libroot.so, libbe.so) as PPC PEF libraries and use it to run BeOS applications. No BeOS libraries, syscalls and protocols are needed. PPC PEF use the same C++ ABI as in GCC 2.
I think the C++ name mangling is different. At least - the gcc compiler that Fred Fish made for BeOS PowerPC had an incompatible C++ name mangling scheme.
I would like to get plain C working and then get the rest in place. The PowerPC C++ standard library was always statically linked, so replacing it shouldn’t be a big deal. It was based on the Metrowerks standard libraries, and those are provided in source form for the Mac Metrowerks compilers, so we can probably at least “see” what it should be when there are any weird PEF issues. I think the regular C++ stuff should just work though, it’s just the bridge between gcc and mwcc name mangling that will probably cause all the issues.
I honestly think we could just use the Retro68 compiler once we have finished it. I think it is a much more recent version of gcc than anything BeOS used on Intel. I don’t know which specific version of gcc off the top of my head (I’d need to boot my Mac to take a look), but it is at least C++17 compatible.
I’m also quite excited by @mmu_man’s ld changes. That might mean the extra tools are not needed? I guess we need to see what happens. ld would need to understand linking other PEF libraries to be a drop in replacement.
The C++ linking was definitely an issue for making XCOFF libraries and linking those via mwld to BeOS code (which is what Fred Fish did) but you are probably right about the PEF exes.
If your PEF tool in your repo now? I want to set it up on my Mac over lunch as that will make developing without BeOS available easier.
I think one project to do after this is get the emulation working so that we can test all of this without having to have a BeBox/Mac desktop near by. I think your Haiku PEF layer would be a very nice way to do that.
I agree that would be really interesting, but I suppose there is probably not much PowerPC-only BeOS software that would make something like that very useful from a user’s point of view.
But in combination with a port of Darling, this could be quite interesting once that project progresses to a point where it can run more GUI applications.
For the emulation part, there is an open source Power PC emulator that could be adapted, PearPC, which even includes a JITC for 32 and 64 bit Intel platforms, but it’s licensed under GPL (hence it probably couldn’t be shipped with Haiku), plus it hasn’t seen any updates since mid 2015.
The apps for PowerPC pretty much run from PR2 onwards under R5, so there are a lot of early apps that you otherwise miss. The other thing is that there are a few weird ones, like the Java port that Metrowerks released for BeOS PowerPC. I mean, Java never really made it to BeOS. But yeah - most apps were compiled for Intel so the library is smaller.
I’m interested because emulating BeOS on PowerPC is currently impossible. There are no emulators that I know of (happy to be corrected), that can boot BeOS PowerPC to Tracker. None of the PowerPC emulators that emulate a Mac emulated the right vintage. BeOS only booted on oldworld PCI PowerMacs with a 603 or 604 processor, and the BeBox.
Getting a modern compiler means we can port modern C based apps to PowerPC more easily and if we can make the C++ stuff work, we are laughing really.
I made a small step forward - I think I managed to get to the point where I have improved the __start entry point to accept command line args and also done a little of the basic set-up needed. Have a look at this update for more info.
PearPC is not maintained anymore, hasn’t been touched for 10 years, you’re better off with QEMU in any case.
There were several attempts at adding a proper BeBox target to QEMU, including from me. Just needs some time to get it finished. That or some oldworld mac.
True, but even if you manage to run PowerPC code on Haiku, you will have other problems because of API and ABI changes for these older applications. So that makes it an even larger amount of work. It is certainly a fun and interesting challenge, and good for preserving these old apps in a runnable state, but I wouldn’t really count on it as a way to bring more apps to Haiku, if only because these apps have no sourcecode so we can’t do any maintenance, bugfixes or improvements on them.
This doesn’t really happen as much as you would think. From PR2 onwards it is pretty rare to find an app that doesn’t work. I used to use the Java SDK from the R3 era under R5… other than being a really old version of Java, it did work. The main issue for PowerPC is that the Media stuff went from Audio Server to Media Server IIRC, but the PowerPC build or R5 still has both.
