Hacker News Reader

Comment by londons_explore | Hacker News Reader

I forsee RISC-V ports of Android rapidly gathering speed...

Ports of Android 12 are already running on dev boards. Most of the work was done by Alibaba, and Google has just agreed to merge it into AOSP, making RISC-V a supported Android platform.

If they do, all that's needed is a good compat layer that can emulate ARM for app compatibility, and the app ecosystem to be updated to compile all the native code to RISC-V for new apps too. Intel tried and mostly failed at this step, with Googles help, so it's a tough task.

View on HN

Remember most native libraries are native libraries because they do some compute-heavy task. They probably involve lots of hand crafted SIMD ARM assembly. Porting that to RISC-V isn't trivial, and most app developers can't be bothered for the tiny number of low-end RISC-V users.

Instead, those users end up using the ARM apps via an emulator, and that makes them even slower on an already slow cheap phone.

End result: RISC-V gets a reputation as a very slow and very crap CPU architecture. Just like MIPS and x86 on mobile got.

Apple transitioned from x86 to ARM in less than a year.

It can be done, using mix of native applications and emulation. And as long the emulation speed is indistinguishable from native (Like Rosetta 2), end users won't notice it and won't complain.

Google & Meta can team up to transition all their apps to RISC-V and that would be 70% of the most used daily apps, other will follow the lead.

> in less than a year.

I think they'd been working on it for many years beforehand. Getting the software stack ready for a new architecture, especially one where there is a lot of 3rd party code you can't touch, is a lot of work.

After all, step one was porting their darwin kernel in 2007. Then the 'Unified Platform' work of 2017 made the userspace work on ARM... Then 2020 they released an ARM desktop product... So it was a lot of years!!

I think you'd be shocked how much of my NixOS system not only natively compiles for my Vision Five but also cross compiles to it... (and Nixpkgs cross compiling support has room to improve, so..)

Obviously a monorepo of largely FOSS is easier to deal with than random Android apps but I don't think it's that dire or insurmountable.

> And as long the emulation speed is indistinguishable from native (Like Rosetta 2), end users won't notice it and won't complain.

Apple could do Rosetta 1 and 2 because the emulated CPU was considerably slower the new architecture. No evidence at all that this would be the case here.

Apple could do Rosetta 1 in about a year because they’d been running on x86 for years internally and licensed Rosetta from QuickTransit.

Hmm ..makes me wonder if something like transmeta can be revived with risc-V.

Well. QuickTransit was from Transitive Corporation, which was acquired by and then demolished by IBM, a bunch of the people from there are now at Apple, for one. The ideas are pretty straightforward and many of them show up in JITting emulators and high-level emulation approaches. I haven't seen an analysis of Rosetta 2 but I imagine it is pretty similar.

Transmeta is different - Transmeta Crusoe etc. were a weird VLIW-like ISA plus their ISA-specific code morpher sw.

Apple transitioned from x86 to ARM in less than a year.

Apple started a lot earlier than the announcement and hasn't completed the transition yet (Mac Pro). A lot of companies better have had RISC-V initiatives in the pipeline already.

NEON isn’t a great SIMD design and is rather old. Everyone’s already needing to start porting to SVE for ARMv9 anyway. At that point, porting to another ISA at the same time isn’t a huge deal as you’ you’re already in the code.

If you put RISCV and ARM assembly next to each other, you’ll see that RISCV is much easier for humans. The vector extension is also much easier to understand than SVE.

I believe porting old NEON too RISCV vectors will be easier than porting to SVE.

thanks for that remark. Do you know of any good resources to learn about developing for SVE for folks who are familiar with NEON/AVX ?

Excuse my ignorance but aren't app packages compiled ahead of time on Android anyway?

Packages consist of a bunch of java-like bytecode, and some native code. Usually the native code is for video decode libraries, neural nets, openssl, javascript engines, speech recognition stuff etc.

The bytecode is platform agnostic, but the native code isn't.

When the app is installed or run for the first time, the bytecode is compiled on device and will run fine. But the native code from the package will have to be emulated if the app is to run. Since the native code might want to link with system libraries (libc etc), there needs to be a rather complex shim to keep everything working properly.

Reply on news.ycombinator.com