9 ms·

>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

• philliphaydon 4y ago
  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?
  • snvzz 4y ago
    >dotnet Is the single remaining major runtime that's still not ported to RISC-V. Therefore, the answer is: Not yet.
    • philliphaydon 4y ago
      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!
      • snvzz 4y ago
        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.
    • HideousKojima 4y ago
      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 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.
  • themerone 4y ago
    Risc-V is an completely different instruction set from ARM. Risc-V is no more compatible with ARM than ARM is with Intel.
    • mark-r 4y ago
      Apple's ARM is more compatible with Intel than you'd expect. https://news.ycombinator.com/item?id=33635720 https://news.ycombinator.com/item?id=33635720
  • vineyardmike 4y ago
    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.
    • philliphaydon 4y ago
      Yeah so for .NET I target win-x64 or linux-x64 or linux-arm64, but I guess .NET needs some linux-riscv or equiv.
      • preisschild 4y ago
        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.
    • raincom 4y ago
      Or one can come up with Rosetta 2 like solution until all binaries are ready for risc.
  • magicalhippo 4y ago
    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.
    • snvzz 4y ago
      >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.
      • anamexis 4y ago
        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.
        • raincom 4y ago
          There is a penalty for translating arm instructions into risc on the fly. That can be compensated by faster risc cores.
        • brucehoult 4y ago
          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".
  • prabhu-yu 4y ago
    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?
• KRAKRISMOTT 4y ago
  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?
  • snvzz 4y ago
    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).
    • retrac 4y ago
      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.
• saagarjha 4y ago
  arm64 was essentially designed from scratch. What makes it have any more baggage than RISC-V?
• wyldfire 4y ago
  > 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.
  • zozbot234 4y ago
    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.