Hacker News Reader

Comment by 2bitencryption | Hacker News Reader

Someone fill me in - are all my understandings here correct?

1. ARM is a RISC architecture, but it is proprietary/licensed, subject to export law, etc.

2. ARM is having a heyday, powering just about every mobile device, plus Apple's recent M1/M2 chips, and is also becoming more common on supercomputers and on servers

3. RISC-V is also a RISC, as the name implies, but is owned by a non-profit and intends to be open and easy to license

So next I would ask, do recent developments that make ARM so promising also make RISC-V promising? Do the decades of work that it took to make ARM the rising star also apply to RISC-V? How far away is RISC-V from being competitive with ARM at a technical level? Or is it already there?

Bonus question... given that both ARM and RISC-V have similar goals, how feasible is an abstract layer on top of them? Meaning, five years from now, how possible is it that I have a RISC-V phone that can run ARM binaries, and and ARM phone that could run RISC-V binaries?

View on HN

>How far away is RISC-V from being competitive with ARM at a technical level? Or is it already there?

RISC-V caught up, key functionality wise, with the set of extensions ratified in December 2021.

There's key advantages to RISC-V, licensing aside. It leverages industry experience and avoids many pitfalls thanks to not dragging any baggage.

Field experts such as Jim Keller sing praises about it.

So I don’t understand any of this stuff. But does this mean applications built for ARM64. Like a .NET 7 app which targets linux-arm64 and runs on… say Ubuntu ARM. Will run on a RISC-V cpu?

>dotnet

Is the single remaining major runtime that's still not ported to RISC-V.

Therefore, the answer is: Not yet.

Hahaha ok. But I could use rust or go without (or without much) issue?

I was worried this might be something we have to wait another 5 years for decent support for but it sounds like it’s quite widely supported now which is awesome!

Yes, Rust has been ported for a while. It's fine.

Keep in mind, there is already 95%+ of Debian's package library, and that's the Linux distribution with the largest package library.

On the topic of Rust, oreboot runs in multiple RISC-V boards. That's Rust running right from power-on/reset.

Technically Mono supports RISC-V, so you can get .NET code running on it. Also it looks like if you're willing to go through messy and poorly documented build processes you can build CoreCLR on RISC-V: https://github.com/dotnet/runtime/issues/36748

So proper support is likely coming soonish, I'd guess by the time .NET 8 or 9 comes out.

Risc-V is an completely different instruction set from ARM.

Risc-V is no more compatible with ARM than ARM is with Intel.

Apple's ARM is more compatible with Intel than you'd expect. https://news.ycombinator.com/item?id=33635720

Applications built for one don’t automatically run on others the way intel/amd have parity for a x86 processor. It is still a different architecture so you still need to compile for RISCV.

Yeah so for .NET I target win-x64 or linux-x64 or linux-arm64, but I guess .NET needs some linux-riscv or equiv.

Yup. In Go the target is called `riscv64`.

But someone could come up with a translator which compiles arm64 or amd64 binaries into riscv64, similar to how Apple's Rosetta2 and box64 does it for arm.

Or one can come up with Rosetta 2 like solution until all binaries are ready for risc.

RISC is just a broad categorization of the instruction set, based on some of its defining properties.

The actual instruction sets are not compatible: they both have different instructions, different ways of encoding instructions and so on.

It's a bit like an AK-74 and an AR-15. Both are classified as assault rifles based on some defining properties, but they're designed and built completely different, so you can't take say a full magazine from an AK-74 and make it work in an AR-15.

So no, you won't be able to take your ARM binary and run it unaltered on a RISC-V core.

>So no, you won't be able to take your ARM binary and run it unaltered on a RISC-V core.

There's still emulation, which will run your unaltered ARM binary... with the corresponding performance penalty, which could either be acceptable or not for the intended purpose.

Would ARM on RISC-V emulation have lower overhead than, say, x86-64 on ARMv8? I would imagine the common RISC stuff would be beneficial there, but I know next to nothing about CPU architecture.

There is a penalty for translating arm instructions into risc on the fly. That can be compensated by faster risc cores.

No. Both x86 and ARM are very expensive to emulate on another ISA, primarily because of the intricate details of updating their respective status registers / condition codes after each instruction. In an emulator, getting that right takes a lot more work than doing the actual add or xor or whatever the instruction appears to do.

RISC-V on the other hand is very easy to emulate at high performance because it doesn't have condition codes at all. Rather than doing something like "cmp A,B;blt foo" as x86 and ARM do (with the result of the cmp stored in the condition codes), the equivalent RISC-V code is "blt a,b,foo".

AArch64 doesn't rely on NZCV that much. Unlike AArch32, most instructions can't run conditionally anymore, it's mostly just the usual conditional branches. Like on RISC-V, cb(n)z and tb(n)z perform comparion/bit test together with a branch in the same instruction.

Yes, but it's not specific to "common RISC stuff", but instead it's because of a peculiarity of the x86 family, which has a strong memory ordering, while both ARM and RISC-V have a weak memory ordering. Apple avoided that overhead by adding a special strong memory ordering mode to its processors, which is enabled while running their x86 emulator; but emulators running on other processors (unless they have the RISC-V TSO extension or similar) either have more overhead, or have to use only a single core to run the emulation.

I group emulation under "altered", as the instructions are not executed by the hardware directly but rather translated into other instructions be it directly or indirectly.

Of course, it's hardly a black and white thing.

Do not worry too much on running ARM or x86-64 or mips binary on RISC-V. You will soon start cross compiling the source code to the target architecture. Running the binary of other arch to another is temporary solution. Rather we need to think on what RISC-V enables us compared to ARM?

The ISA standard only specifies the instruction set. The actual technology in pipelining designs and gate layouts are still proprietary. Are there significant advantages to having an open ISA? Better software support?

Even ignoring RISC-V's already excellent toolchain and software ecosystem support, and the license everybody gets for free (which is a huge deal), there are technical reasons.

RISC-V is designed with great care taken to weight all decisions as not to hamper any scope of implementation, from the lowest power microcontrollers to the fastest supercomputers, and everything in between.

This is unlike e.g. ARMv8/aarch64, which imposes too much complexity (>700 instructions) to small implementations, and hampers all implementations due to low code density.

In small implementations where performance isn't paramount but 64bit is required (for e.g. addressing, as is the case in many specialized tiny cores embedded in larger SoCs), bad code density increases ROM and/or RAM requirements as code takes more space, thus area and power. If 64bit is not needed, aarch32 can be used, which has much higher density, yet as of recent B and Zc extensions, RISC-V is better still, and can be tailored to the requirements, down to as simple as ~42 instructions and 16 registers (rv32e).

In large implementations, such as Apple's M1/M2, aarch64's awful code density imposes a large L1$ code cache in order to keep the pipelines fed. Large L1$ are very costly, as latency, area and power go up quickly with cache size, and maximum clock drops as size increases. Keep in mind that, in current fab nodes, SRAM is far more costly than logic

In contrast, RISC-V offers industry-leading code density through a form of variable instruction size that takes great care to not complicate decoder parallelism. There are already multiple large scale RISC-V cores announced with 8-wide decode (like Apple M1/M2).

Great point. At the low end, there are the 8-bit microcontrollers that cost a few cents. Far larger than that, a fast 64-bit multicore chip, costs at least a few dollars. There's a large space in-between. A current laptop or desktop machine will have many, perhaps literally dozens, of 32-bit microcontrollers on the motherboard and in the peripherals, often integrated into a larger IC. There are multiple processors, besides the main processor, in most mobile devices. In recent years, this area has been largely controlled by ARM.

For something very simple, an in-order 32-bit processor with nothing but simple integer features, RISC-V does appear to be a bit simpler to implement than the current embedded ARM instruction sets. Less state, fewer and more regular instructions. In a large machine throwing away some tens of thousands of transistors on that is an irrelevance. But in a 10 cent microcontroller it is not. As 32-bit and 64-bit computing displaces the 8-bit embedded world, I think RISC-V has a small technical advantage in that area at least.

> RISC-V is designed with great care taken to weight all decisions as not to hamper any scope of implementation, from the lowest power microcontrollers to the fastest supercomputers, and everything in between.

RISC-V was consistently designed so that the simplest implementations remained as simple as possible. When design tradeoffs meant more complexity for more performant designs, any possible detriment was determined to be unimportant.

Notoriously, this is the whole "big cores can fuse instructions; that's got to be free for them, right?" Though the V extension also has a couple of fun ones with re-using v0 for masking (oh a big core can just keep track of whether it's a mask or not and switch which set of registers it's renaming from) and vsetvl (yeah let's make a big core speculate what effect it'll have on subsequent instructions)

> aarch64's awful code density

All the code density comparisons I've seen have been static. Do you know of any dynamic comparisons? I suspect 10% less dense code than RISC-V C (but still denser than x86-64) isn't the primary reason for having 3x more L1I than I think any RISC-V or x86 design currently has...

And even then, ARM for instance decided it was worth spending 50% of L1I cache area on a MOP cache for various reasons, a key one being that their implementation shaves off a cycle in branch mispredicts. If there's no predecode info stored in cache, I can easily see a predecode stage adding a cycle to the pipeline depth over assuming fixed-length. And if it is stored in SRAM you lose some of the codesize benefits...

I thought the sizes of data caches were far more important than instruction caches? I mean even if the ISA is not as dense as it could be, we're talking about a few kilobytes of wasted i-cache space at most.

Well, that's like 10% of your I$.

> […] aarch64's awful code density […]

With all due respect, this is complete nonsense. You keep making this claim, yet have never produced any credible evidence other than a single bogus «ls -l /bin/bash» ages ago for three – x86, aarch64 and RISC-V (was it RISC-V 64 or 32?) – Linux distributions where the code was most likely compiled with «-O2 -g». If you want to substantiate your claim, you had better provide an objdump output for the _text/.text section that will reveal the actual (i.e. pure) code size footprint.

Let's pick this apart. The same random C++ code compiled with the same GCC v12.2.0 for 1) aarch64 (a generic 64-bit aarch64), 2) RISC-V (a generic 64-bit target), and let's also throw 3) POWER64 and 4) MIPS64 in for giggles:

– aarch64: https://godbolt.org/z/r4WPPj8nG

– RISC-V: https://godbolt.org/z/sr6nb8sTc

– ppc64: https://godbolt.org/z/PMrhe5W8z

– mips64: https://godbolt.org/z/sdKjncEfq

If we filter out empty lines, labels, assembly pseudo-instructions and directives, we get the following results (in the ascending order) as the number of actual instructions for each ISA:

  aarch64: 
  $ rg -cv '(^ *\.)|(^$)|(^[ A-Za-z0-9\(\)_]*:)' /tmp/meta.arm64-v8a.S
  814

  RISC-V 64-bit:
  $ rg -cv '(^ *\.)|(^[ A-Za-z0-9\(\)_]*:)' /tmp/meta.risc-v.S
  860

  ppc64:
  $ rg -cv '(^ *\.)|(^$)|(^[ A-Za-z0-9\(\)_]*:)' /tmp/meta.ppc64.S
  945

  mips64:
  $ rg -cv '(^ *\.)|(^$)|(^[ A-Za-z0-9\(\)_]*:)' /tmp/meta.mips64.S
  1030

aarch64 has, in fact, the lowest instruction footprint and came out at the top, with RISC-V trailing behind (but being comparable nevertheless). Surprisingly, ppc64 did more than 10% worse than aarch64, and mips64 came in last (unsurprisingly).

Conclusion: aarch64 does not possess the «awful code density» and is comparable to or better than that of the RISC-V 64-bit architecture.

Number of assembly instructions is not strongly related to code density. In any case you need to look at dynamic code density to draw any conclusions about I$ pressure.

Even if your comparison was valid, it is affected by the quality of the compiler - current compilers are not very good at exploiting RISC-V compressed instructions and generally have not had as much attention as on older architectures.

And that is why I used the same compiler for all ISA's: gcc 12.2.0. The GIMPLE IR intermediate product is the same for all architectures; however, the ISA backend is specific to each ISA, so code generation peculiarities might or might not be an issue. GCC code output quality is above the average or high for all active mainstream architectures.

Also, RISC-V compressed instructions are RISC-V 32-bit, therefore a comparison with 64-bit architectures is not applicable.

> Also, RISC-V compressed instructions are RISC-V 32-bit, therefore a comparison with 64-bit architectures is not applicable.

No, both 32-bit and 64-bit RISC-V have compressed instructions, and they're nearly identical (IIRC, there's one compressed instruction which is different).

Does this account for the ubiquitous riscv compression extension?

The compression extension is RISC-V 32-bit. All code has been compiled for 64-bit architectures for a comparison.

That is not correct.

Compressed instructions are available for 32-bit (RV32) and 64-bit (RV64). The compressed instructions differ slightly between the two though. See my other comment in this thread.

I am more than happy to stand corrected, if a correction is warranted. What is the gcc 12.2.0 -march= value to make gcc 12.2.0 emit the compressed 64-bit code? The gcc 12.2.0 rejects all the -march RISC-V values the gcc documentation cites, e.g. rv64i is not accepted, and it is documented. I had presumed it was -march=rv64Zc[…], with […] being a combination of a/b/c/d/f/cmp/cmt, and neither of those was accepted.

Also, according to https://wiki.riscv.org/display/HOME/Specification+Status, code size extensions are in a review state slated for a ratification in Q1 2023, with «ABI issues being worked» mentioned in the notes. My interpretation is that the compressed instructions extension is still work in progress, and is a moot point to discuss at this very moment.

> My interpretation is that the compressed instructions extension is still work in progress, and is a moot point to discuss at this very moment.

The compressed instructions extension (the C extension) has been finished and standardized for a long time. In fact, all mainstream desktop Linux distributions which have ported to RISC-V have standardized on RV64GC (aka RV64IMAFDC, with the extensions I, M, A, F, D, C), that is, they require compressed instructions.

So what is the gcc (or gas via gcc) compiler switch to make the RISC-V compiler backend yiled compressed instructions? I have been unable to find a working one in the documentation, and the beehive mind has been of no help either.

Compressed instructions are generated by default with recent versions of GCC for RV64GC and RV32GC.

>My interpretation is that the compressed instructions extension is still work in progress

C was ratified years ago, but I suspect you might have heard about Zc (about to be ratified, specific to 32bit, particularly helpful to microcontrollers) or B (ratified recently, bit manipulation, happens to help code density), and their effect in code density.

Yes and no. The GP is counting instructions, which is approximately the same between ARM64 and RV64. Others are talking about code density where RISC-V currently has a significant advantage due to compressed instructions.

-----------------

For the above code segment, though I selected the compile-to-binary option, and the program failed to compile. So I don't know what's up with that.

On a relatively short chunk of C++ code, you can see the compressed (16-bit) instructions in the binary output:

https://godbolt.org/z/jzjzrrfMP

Some instructions, such as the ones with a larger immediate load, are 32-bit.

Same version of GCC / G++ as the above.

The actual code size of the ARM64 is bigger:

https://godbolt.org/z/Wq7jKz5rY

I'm not sure why all the NOP instructions are in there, but even discounting that, all the generated machine instructions are 32-bit. Is there another option for GCC that will help? Or am I mistaken in thinking there is a Thumb2 equivalent for this target?

Edit: Answer: No. A64 is fixed-length:

https://developer.arm.com/documentation/den0024/a/An-Introdu...

For the sake of savouring a civilised nerdy discourse, may we stick to the same code and set a rule that only compiler switches can be fiddled with? Comparing 3 lines (after discarding empty lines, curly braces, functions and variable declarations) of unrelated code (which is not a C++ code anyway) yielding a 5 or so CPU instructions is boring and is not enlightening in our quest to reveal the light and unveil the path to truth.

The piece of C++ code I have uploaded to GodBolt was floated on HN a few years ago as an instance of the template metaprograaming that crashed one C++ compiler and resulted in an OOM process kill for another (for the record, it was clang++ and g++ although I can't remember which one did what). Both compilers have been fixed since then, but the code is still interesting due to it being: a) terse, and b) resulting in a unusually large number of [mostly useless] numeric computations that a C++ compiler yields by virtue of the template expansion. So I have retained a copy of the mischievous code. The template expansion is common in C++ template metaprogramming, and is extensively used in C++ scientific libraries (e.g. BLASS as well as in others).

When it comes to the generated code footprint comparison, the numeric computations are a good metric to assess.

I compiled that code with slight modifications (needed an actual func1 function) with a cross-compiler I had laying around into actual executables:

cross g++ version 8.4.0 for aarch64: 13712 bytes

native g++ version 11.3.0-3 for RV64GC: 13968 bytes

... but that includes a bunch of startup stuff, so that's not a good measure.

Modifying the code to generate binary on godbolt:

ARM64, 3816 bytes: https://godbolt.org/z/vn3de5nEc

RV64GC, 3226 bytes: https://godbolt.org/z/4ovMTaxo9

So an 18% increase in code size for ARM 64-bit vs RISC-V 64-bit. As you can see in the generated code, there are 16-bit compressed instructions by default with the RV64GC binary.

This is excellent, thank you. I was under the impression that the compressed instructions set required a dedicated compiler switch, and counted a number of instructions instead. Now that «X is 18% smaller than Y» is quantified, there is the circumstantial evidence, and it gives a clearer idea of the differences between two ISA's. Yet, it does not validate the absolutist and unquantifiable «awful code density» statement.

I have also noted that compressed and uncompressed instructions are unevenly interleaved in the generated code, and occur in random sequences, i.e. addresses 0x10a60 ÷ 0x10a72 follow the 16-32-16-16-16-16-32-16 bit sequence whereas most other instructions follow 16-32 bit or 16-32-32 / 16-16-32 bit sequences. I wonder what performance penalty for the instruction decoding unit in hi-perf RISC-V cores is going to be for compressed vs uncompressed instructions code especially if the instruction being decoded spills over into the next L1 i-cache line (or, worse, into another memory page). RISC architectures are generally averse to misaligned memory access.

>yet have never produced any credible evidence other than a single bogus «ls -l /bin/bash» ages ago

Wait WHAT? I strongly suspect you're confusing me with somebody else I am not.

Please use `size` from binutils, if you're trying to compare code size of binaries.

The greatest advantage is that you can make your own processor implementing the ISA without asking for permission and/or paying fees. Also you can make your processor open source if you wish and many have already done so.

As an example Apple designed their processors from scratch, they do not use any core designs provided by the ARM holdings corporation. Yet they still have to pay ARM a lot of money because they use their instruction set.

The instruction set is a very sticky thing. All the software gets written for a particular instruction set, and people like to keep using previously written software. Thus, software stickiness causes CPU ISA stickiness which gives companies that control that particular ISA a lot of power. And they of course monetize that power by charging extra for their CPUs.

With an open ISA, anybody can make processors that use the same instructions, which means that your software should work on any CPU designed for that particular ISA. Thus, all the talented hardware designers in the entire world can work to make RISC-V processors without asking for permission. They are free to charge for their designs or make them open. And if you write RISC-V code, it can execute on any of those processors or any future ones anyone decides to develop. (There is a bit of complication here in that the RISC-V ISA includes several different combinations for instructions for different use cases, but they are all open).

> Yet they still have to pay ARM a lot of money because they use their instruction set.

Is this true of Apple? They co-founded ARM, I thought it was believed they had a perpetual license.

That doesn’t exempt them from royalty payments.

Ah, I see.

Lots of techniques are covered by patents.

What are expiration dates for today's most important techniques ?

And you're right, a vendor could incorporate novel patent-encumbered instructions into their otherwise RISC-V (based) CPU designs. In which case perfect compatibility wouldn't be possible.

Patterson, I believe, has said that folks like Intel intentionally do this, add rather pointless new patented instructions so that they are always "embracing and extending" (my words) their own designs to prevent true compatibility; and thus cloning by others. And that that's one big reason why it was worth creating RISC-V.

> The greatest advantage is that you can make your own processor implementing the ISA without asking for permission and/or paying fees.

This is great but if one or all the parties in a commercial war decide that your product cannot cross a border, an open source design won't save your business.

arm64 was essentially designed from scratch. What makes it have any more baggage than RISC-V?

> RISC-V caught up, key functionality wise, with the set of extensions ratified in December 2021.

Having an ISA with functionality parity is the table stakes. But having designs actually capable of outperforming the current generation of ARM cores will be a real challenge.

Can SoC vendors design their next generation with RISC-V application cores? Sure, but no one will want it if it's slower or results in lower battery life. So far they've mostly only dipped their toes in the water with RISC-V microcontrollers. Google's explicit desire for a tier-1 RISC-V Android probably will help break a stalemate and get SoC vendors to ship something. It will very likely not debut as a flagship. But releasing a RISC-V phone that performs "adequately" would be an accomplishment that will flush out a lot of issues.

RISC-V chips so far have been significantly lower-area and higher efficiency than their closest ARM counterparts, when on the same fabrication process. This has held true for embedded microcontrollers and lower-end application processors. And RISC-V with the newly standardized extensions and Rva-22 profiles seems to have even more potential at the higher end. It obviously won't make a huge difference to battery life, but it shouldn't hurt either.

RISC vs. CISC is irrelevant.

ARM vs. RISC-V is irrelevant

The only thing that really ever matters is the quality of any given specific CPU implementation, which has almost nothing to do with CISC vs. RISC or the ISA[1]. x86 has been dominate for so incredibly long because Intel just consistently made the best processors around, and #2 in the space was also usually AMD. This is why Apple switched to Intel in the first place, after all. Don't forget that Apple switched off of RISC to CISC and got huge increases in performance & efficiency as a result.

Apple's M1/M2 are good because they invested an absolute shit-ton of money building up a seriously good in-house CPU team over the past 10 years, not because it uses ARM's ISA. In fact, M1/M2 support x86's memory model - it's a key reason that Rosetta 2 runs so fast.

So for a RISC-V phone to show up in let's say the mid-range or higher market and be competitive would take someone actually building a good RISC-V CPU implementation. Which maybe sifive will pull off - their new performance lineup looks decent enough on paper anyway. But that's also compared to the 2-year old Cortex A78 which is itself quite a ways behind Apple's M2 / Bionic A14. So that's what you really need to find for a RISC-V phone/laptop/whatever to be interesting - someone who can, ideally consistently, deliver a CPU core design that's competitive with {Apple, ARM, Intel, AMD}. And that list only even barely includes ARM - their CPU cores are by far the weakest of that set. Which is itself a significant asterisk on the whole "ARM servers!" thing.

1: the small but significant asterisk on that is it's plausible, if not likely, that Apple was able to build an 8-wide CPU frontend as a direct result of armv8 not being a VLA ISA whereas x86_64 is. However that's also arguably more a function of the ISA's encoding than the ISA or CISC vs. RISC debate. In theory you could have an x86_64 instruction set that's not VLA, just like ARM used to have thumb/thumb2 and non-thumb modes back in the day.

> And, and I can tell you that we got pretty far along with an internal Arm design, and it was very, very clear that you if you’re delivering a certain level of performance, the delta in power driven by the ISA is like 5 percent. [1]

Power matters a lot and 5% isn't almost nothing. And that's an estimate from an x86 vendor.

Agreed that it's almost certainly third though behind process and design. Intel's CPU leadership for a long time of course is not unconnected with its process leadership.

[1] https://www.nextplatform.com/2022/10/03/the-steady-hand-guid...

Idk for phones and larger I'd say 5% power reduction is still pretty close to nothing, especially if that's the difference between x86 and ARM. A 5w SoC becomes a 4.75w SoC - nobody is going to bat an eye at that. Similarly a 50w laptop CPU dropping to 46w is hardly transformative. It's not nothing, but it's still significantly less than a node shrink even with Moore's law being dead. And the difference between ARM and RISC-V would likely be even smaller.

You could also save way more than 5% power by just optimizing user space a tiny amount

It's not huge but it's not irrelevant either. Plus I think its probably an understatement (being from an x86 vendor).

I agree that the focus on ISA is often a bit overdone just not that it's something we can ignore.

Fair, and there are also of course ISAs that could be drastically impactful like the ill-fated Itanium or the doesn't-seem-to-be-real Mill.

Agreed. I think it's hard so see a new ISA getting much traction now unless it clearly offers a very significant power / performance benefit and that seems unlikely at the moment. I blogged that RISC-V might be the last mainstream ISA a while ago - I think it will crowd out other options.

Does this mean that vendors with already good ARM CPUs can fairly easily convert them into good RISC-V CPUs? If so, is anyone doing it?

I don't know about "easily" but let's assume sure, who would you even consider doing it? The biggest non-"reference" CPU core design is Apple's, and Apple is an ARM ISA founder so why would they care about switching to RISC-V?

For others, like Qualcomm, Samsung, or Amazon, they are licensing the ARM-designed CPU cores not designing their own in-house. So they wouldn't be able to switch those to RISC-V, it's not their IP.

> Bonus question... given that both ARM and RISC-V have similar goals, how feasible is an abstract layer on top of them? Meaning, five years from now, how possible is it that I have a RISC-V phone that can run ARM binaries, and and ARM phone that could run RISC-V binaries?

That’s called Java and Android already has it

I'd say it's more along the lines of Qemu user emulation / Rosetta 2 / Microsoft's x64 on ARM64 JIT.

I'm not sure the fact that RISC-V is RISC means much. Seemingly every new CPU ISA designed since 1990 has been RISC. Only Arm's has taken off in a big way outside specialist applications. CISC CPUs (x64) are still around and still competitive too.

Reply on news.ycombinator.com