9 ms·

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

• snvzz 4y ago
  >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.
  • 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.
• deleted 4y ago
  [deleted]
• pantalaimon 4y ago
  > 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
  • bpye 4y ago
    I'd say it's more along the lines of Qemu user emulation / Rosetta 2 / Microsoft's x64 on ARM64 JIT.
• TazeTSchnitzel 4y ago
  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.
• kllrnohj 4y ago
  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.
  • klelatti 4y ago
    > 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-guiding-amds-prudently-expanding-datacenter-business/ https://www.nextplatform.com/2022/10/03/the-steady-hand-guid...