You'd have to go through a lot of hoops like LLVM, compiler, etc CPU support just to get a Mac OS app written in Swift visible on the screen on OS9. Very interesting technical read on CPU support, compiler support, no matter the usefulness.
It would be interesting to upstream the LLVM-related work. And I do wonder how much work would it take to support other PPC32-based platforms - not just Apple and BeOS but AmigaOne, GameCube/Wii, *NIX and WinNT 3.51/4.0 systems etc.
As for WinNT and other non-ELF platforms systems, that's retro hobbyist territory, not very likely to end up in upstream LLVM. But you could always convert object files into the right format externally! e.g. for years building TianoCore EDK2 on non-Windows has involved conversions from ELF to PE (now there's also a CLANGPDB setting that produces PEs directly from LLVM)
m68k seems to be mostly a hobbyist interest rather than a commercial interest at this point. The problem is, if the person whose hobby it is gets busy and then either the whole project is getting held up by that backend, or it just gets removed.
At least in case of PPC and System z, IBM has a commercial interest in making LLVM work for them – and the former has some hobbyist/retrocomputing benefits as an unplanned side-effect. (System z, much less so – modern System z is 64-bit, whereas most of the mainframe hobbyist community focus is on the legacy pre-1980s 24-bit architecture.)
m68k isn't just one person's hobby however - there's a sizeable retrocomputing community around it.
> and then either the whole project is getting held up by that backend, or it just gets removed.
LLVM has a notion of "experimental" backends that's precisely meant to avoid this. Unfortunately it's a bit misused at present, with backends that have little reason to be "experimental" being marked as such for historical reasons, while stuff like m68k (and perhaps this new PPC-based stuff) that could use it gets left out altogether. This should be fixed.
> m68k isn't just one person's hobby however - there's a sizeable retrocomputing community around it.
But how many people in that community have the skills to maintain the LLVM backend?
I agree it would be great if m68k made it in LLVM, I'm just trying to explain why the LLVM developers seem so hesitant about it.
A thought: if there is really enough interest in LLVM for m68k, those interested could set up a not-for-profit membership association with annual dues, and then the association could use those dues to hire a developer to work full-time (or even just part-time) on LLVM+m68k. I think if an arrangement like that existed, the LLVM development team would be far more likely to say "Yes". If 1000 people were all willing to pay $100/year to support this, that would make available $100,000 per annum to fund development.
IBM is doing most of the work wrt. this backend to support their AIX systems. Support for other platforms mostly comes along for the ride.
(For that matter, LLVM might well pick up a backend that has sufficient maintenance to keep up with internal code changes, regardless of "production" concerns. See RISC-V as an example - obviously it's not seeing a lot of production use, but LLVM does include it.)
Impress me further if you can do that with BeOS.