4 ms·

There are no ports of Firefox or Chrome for RISC-V. I believe the JavaScript engine is the problem.

by drmpeg 5y ago

blt 5y ago
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.
- classichasclass 5y ago
  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-jit-progress.html 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).
  - spijdar 5y ago
    > 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.

There are no ports of Firefox or Chrome for RISC-V. I believe the JavaScript engine is the problem.

by drmpeg 5y ago

There are no ports of Firefox or Chrome for RISC-V. I believe the JavaScript engine is the problem.

blt 5y ago

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.

classichasclass 5y ago
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-jit-progress.html 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).
- spijdar 5y ago
  > 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.