Thanks. I'm kind of surprised that Firefox doesn't have the ability to compile with a pure C/C++ platform-independent javascript interpreter for odd architectures.

It does, actually: the POWER9 Raptor Talos II I'm typing this on uses the C++ interpreter entirely right now. (We're working on a JIT: https://www.talospace.com/2021/07/firefox-90-on-power-and-ji... ) I don't see any reason you couldn't build Firefox on a RISC-V system.

EDIT: Actually, there is a reason, but it's not JavaScript. Firefox needs stubs written for XPCOM to map the ABI for XPConnect calls. Once this is done, it should "just work;" it's not difficult (I rewrote them for ppc64 myself).

> Once this is done, it should "just work;"

Unless it doesn't cough ppc32 cough

Nowadays you have to contend with Rust, LLVM, Skia, and the other porting headaches...

There are XPCOM stubs for a lot of platforms in Mozilla. Mostly bitrotted, but even if they're fully restored, I just don't think Firefox is that portable anymore.

Although apparently there's a RHEL package for Firefox on s390 that worked fairly recently, so I dunno.

EDIT: Using Debian as an example, the latest version is available on x86{_64}, ARM{64}, mips64, and ppc64le. And s390x. ppc64 is in debports.

32 bit MIPS is lagging behind a few versions, no idea if it just hasn't been rebuilt or there's a new blocker. sparc64 is stuck on 62, it probably can be patched up but judging by some bug reports is sort of similar to ppc64{le} in needing some TLC, and I doubt anyone is really using it. hppa/m68k are stuck on 52/50, left behind with the move to Rust I'd assume.

All I'm saying is in practice I'd expect porting firefox to a new platform to be a pretty involved effort. Even if you have LLVM and Rust support, there's a lot of moving parts inside, and it's not like the old days where most of the platform specific bits were inside NSPR.