Support for powerpc, riscv etc.

[barracuda156]

There was an archaic ticket re support for less mainstream archs, but it is locked: #73

Has there been anything done ever since in this regard? Makefile looks like it gonna break on any platform besides x86 and arm64:
https://github.com/jart/cosmopolitan/blob/master/Makefile#L134-L140

[bjia56]

Previous work for supporting alternative architectures takes the form of embedding Blink into the final cross-platform binary, which would emulate the x86_64 portion of the Cosmopolitan libc program: cd27a53

This is no longer part of cosmocc/apelink, however I've been working on bringing it back in some capacity as an optional feature:
#1381
#1383
#1404

Of course, a native architecture port would be more efficient, however Blink does a good job in getting Cosmopolitan programs to run on unsupported platforms.

[barracuda156]

@bjia56 Thank you for the references. I am unfamiliar with this emulator, but its README seems to imply it can be built on anything. (Doesn’t necessarily mean it gonna work on anything, but I can try on a PowerMac.)

Upon re-reading the commit text, I think now it may not work, since PowerMacintoshes there stand for Linux, not Darwin. Doesn’t hurt trying, but if there was never support for PowerPC Darwin, adding it may be challenging. If it was supported but just not being tested, then some chance of getting it to work is there.
This will probably be clear from the build already: if it uses arch-specific assembler, both syntax and ABI differ, so Linux ppc asm code simply won’t compile without some rewriting.

[bjia56]

Since Blink is available as source code, it may be possible to get it to compile on PowerPC Darwin. There might be some tweaks needed if certain syscalls are unavailable (for example, I had to tweak a few things for Solaris in jart/blink#188). Adding it to the APE binary might need some additional work in apelink since my prior PRs only operate on non-MacOS Unixes - the MacOS detection relies on the existence of an /Applications directory, which I'm not familiar enough with PowerPC Darwin to tell if that exists there or not.

[barracuda156]

/Applications is there. PowerPC and x86 were concurrently supported in several macOS versions, so OS structure, UI and to a large extent SDK are identical. Assembler aside, everything else should be portable, unless, of course, the code relies on some kernel functionality which does not exist in 10.5–10.6. I do not know what libc with POSIX 2017 specifically means in requirements. Normally libc is a part of the OS, and the latest POSIX which may be supported on powerpc Darwin will be 2008 (plus Darwin-specific extensions). It is rather means a modern compiler supporting recent standards, that is not a problem.

[bjia56]

One of the limitations you may run into is latency introduced by the emulation layer. Blink currently has an optimized JIT for x86_64 and arm64 hosts, but not for other architectures. Adding JIT support for PowerPC is in theory possible, though requires someone to do the work. (In my opinion, I'd love to see a PowerPC JIT in Blink, since one of my goals is to get Cosmopolitan programs running on the Wii).

[bjia56]

@barracuda156 Out of curiosity, is there a typical MacOS version or Darwin kernel that Mac PowerPC software nowadays targets as a minimum?

[barracuda156]

@barracuda156 Out of curiosity, is there a typical MacOS version or Darwin kernel that Mac PowerPC software nowadays targets as a minimum?

De facto the typical minimum is 10.4 (darwin8); while I saw a couple of times earlier targets in makefiles, I never encountered anyone actually asking for something to run on 10.3 or earlier. There are also purely technical reasons to ignore pre-10.4 systems: toolchain is archaic and perhaps unusable. GCC upstream in principle supported and still supports 10.4+, MacPorts kept 10.4 support until the last release this year, TigerBrew targets 10.4, TenFourFox for years used 10.4 as the baseline. For some (still running and used) ppc hardware 10.4 is the ceiling; on some (weaker) machines it is allegedly more usable, being marginally faster; finally, users who need to be able to run Classic apps cannot upgrade, since 10.5 dropped support for Classic.

Having said that, I do not see much point in using 10.4 as a target for anything new – besides, perhaps, a browser. Later ppc machines (last G4 and all G5) handle 10.5 (and 10.6, FWIW) with no performance issues, Classic apps thing is an isolated niche for old games, 10.5 toolchain and SDK are considerably more usable and easier to support than 10.4. (Say, on 10.5 bootstrapping gcc15 is a neat two step process for ppc, Xcode–gcc10–gcc15, and marginally more involving for ppc64, where a newer ld64 is needed with recent gcc versions. On 10.4 it is a whole quest, since Xcode tools are too old, and MacPorts, I think, used to build gcc 4.2, then new cctools and ld64, then gcc7, then gcc10, then the latest gcc.)

In many cases of real-world apps which do not target legacy macOS and powerpc as such (upstreams do not care to), realistic baseline is either 10.5 or 10.6, which is determined by SDK features expected by the codebase. Going down to 10.4 maybe be non-trivial, have penalties on usability or just be infeasible.
For stuff which I was doing for ppc I only considered 10.5+ (besides occasional extra fixes for 10.4 for something that was requested).

Also, anything which happens to strictly require 64-bit platform can only use 10.5 (in 10.4 support for ppc64 was not mature, in 10.6 it was dropped).

[bjia56]

Thanks for the detailed notes! I'm currently building a Tiger VM to see what it would take to get Blink running, and I can definitely see what you mean. Installing wget via MacPorts seems to be a week-long process involving building several different gcc's...

[barracuda156]

@bjia56 Thank you, this is awesome!

Notice, it could be worthwhile to use 10.5 and just use 10.4 as deployment target. That gonna simplify bootstrap to the modern toolchain. (I don’t know how much it matters to reduce compilation times.)

It might also happen that some port fails to build on 10.4, since aside of bootstrapping gcc14 itself (which was verified to work), little to nothing was tested on Tiger, perhaps for last few years.
Chances that 10.5 gonna work ”out-of-the-box” are higher, but something could still fail (MacPorts tests nothing on it, even on x86, and I stopped submitting fixes to them).

If you face an issue with a port, quite likely the fix can be found here: https://github.com/macos-powerpc/powerpc-ports (though I don’t test on 10.4 either). If it is not, please tag me or open an issue, so that it can be addressed.