Comment by phh | Hacker News Reader

Comment by phh | Hacker News Reader

Google "wants" that, but doesn't seem to push forward on that matter. AOSP gerrit received risc-v jvm CLs 2 years ago from external contributors, and didn't merge any. (sorry, I have no source from Google's gerrit since they regularly clean it up, but you can find https://www.theregister.com/2021/01/21/android_riscv_port/ for related info )

Current state of Android RISC-V support 2 years after those ignored contribution is literally "we have a working libc", which isn't great. My understanding of Google's presentation is that Android 14 (Q3 2023) will have interpreter-only jvm support for RISC-V, no JIT/AOT. (I'm surprised there is no pure C interpreter that would work anywhere, but well). So decent RISC-V support in Android may happen for Android 15, so Q3 2024.

Will there be weird ABI/ISA issues that will need few versions to iron out? Hard to say, armv5 didn't go smoothly, nor armv7 (hi neon-less nvidia), and risc-v's modularity might prove to be challenging on that regard.

Overall, even though Google/Android doesn't seem as pushy on risc-v as they pretend to be, I'd say Google/Android will indeed be ready when the risc-v industry is ready for prime time.

Nobody really wanted to integrate RISC-V support anywhere while the ISA and ABI was unstable. That only really got finalized last year, so I am not surprised that it took this long.

This actually seems like the most reasonable reason to me. It wasn't stable, there was nobody (planning) on making RISC-V devices on which you'd want to run Android, and compiler support was far behind. We're in a very different place now, I would have made that same call (though perhaps would have given more reasoning to reduce speculation).

Is this more about the ABI? I couldn't find incompatible userspace ISA changes since many years (things sounded to have settled down since a while even in 2016: https://riscv.org/wp-content/uploads/2016/06/riscv-spec-v2.1...). The RISC-V Linux port was also merged to mainline in 2017 and presumably been living under the stern binary & ABI compatibility rules there.

Since ISA collections affect ABI in RISC-V, getting an agreement of the baseline for RISC-V ISA for Linux-based systems was extremely difficult. On top of that, the ABI stabilization work couldn't begin until the required ISA extensions for Linux were locked in. So it was all a mess.

(It still is a mess, to be honest...)

My guess is that theyve only recently been asked by handset manufacturers to consider non-ARM chips, for example this would be a great way for Qualcomm to gain leverage over ARM given the recent lawsuit

Android has official x86 & x86_64 support and used to have MIPS support back when MIPS still existed, so this isn't the first "not-ARM" support to happen.

But the change from ignoring risc-v contributions to saying it's important probably did come from a significant SoC manufacturer pushing for it, yeah.

I'm aware of at least one Chinese manufacturer building a RISC-V based smartphone

On what timeline? Are there any suitable SoCs yet?

This one is what I'm aware of: https://sipeed.com/licheepi4a/

Alt: https://linuxgizmos.com/lichee-pi-4a-risc-v-platform-availab...

At the bottom they say they have a tablet and phone planned, though no info on when.

Another possible guess, is that Google wants to start making their own CPU cores to beat Apple (I'm more along your guess, but I've seen so much Pixel-first AOSP development, that I have to doubt)

The timeline looks similar to when I expect the first RISC-V consumer devices to be ready, so they'll be ready in time for that.

The downside is that developers won't be able to test their stuff on the dev boards that are already available, which may harm the ecosystem on launch.

What would be the correct way to handle this in your opinion then? Invest in migrating a massive OS onto the new arch before it's stabilized and has a working SoC with 3D acceleration (which Android needs)?

Reply on news.ycombinator.com