I pushed my attempt at fixing PEF support in LD, just so it’s published somewhere 
2 Likes
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.
1 Like
Ah yeah right, would just need some PEF loader to get them started then.
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.
And userland PPC CPU emulator. Architecture can be following:
- Host runtime_loader loads PPC emulator add-on and pass (argc, argv, env) to it.
- PPC emulator add-on loads PPC PEF runtime_loader into virtual machive and pass (argc, argv, env) to it.
- PPC PEF runtime_loader load and run PPC PEF application.
- PPC emulator add-on forward syscalls to host libroot.so _kern* functions.
I made some investigation of PEF format and made an utility to analyze its contents.
2 Likes
Mangling bridge is technically not needed. All C++ code including libbe.so will be compiled as PPC PEF.
The biggest challenge would be adapting Haiku build system and sources so it can be compiled with Metrowerks C++ compiler.
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.
1 Like
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.
4 Likes
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.
Getting a BeBox emulator would be great. I did find something that got as far as the 3D logo and I think also let you enter the boot menu once. Getting it to boot - even with single processor, would make porting stuff a lot simpler. Having to be close to a BeOS desktop is quite limiting for all of this. Telnet does work, but it would be nicer to have local emulation for testing so that it isn’t a requirement to be running noisy 90’s desktop machines 
MAME can show the bootlogo, but thats all AFAIK.
1 Like
Yeah, I think it was MAME or MESS.
So - the other part of this is setting up a repo for all the old PowerPC software. This is now under way. I have this account on GitHub and I am open to contributions.
The plan is to have a static GitHub Page that we manually maintain and then as new software is added it will be put in to the main repo as source and have binary assets linked on the main project repo. But all the stuff I find will go in to uncategorised to begin with.
I have confirmed that our compiler is building apps with a main function using the BeOS specific __start function I crafted. This means it is probably possible to get C code to compile as long as I can get headers from BeOS to work.
1 Like
Is there any hope for a PPC port this century?