19 ms·

I think he's kind of speaking past the original author. The original piece is basically about how the author doesn't think that RISC-V will take off outside emb

• quotemstr 2mo ago
  Different RISC-V dialects might as well be as different from each other as English is from German. Sure, the cognates, family the resemblance, and common(-ish) alphabet make some things easier, but if you're shipping a manual, you still need to do it both in English and auf Deutsch unless you rely on machine translation. So it is with the family of mutually incomprehensible ISAs called RISC-V.
  • Geof25 2mo ago
    Yeah I know this mess in PowerPC. There is IBM Power, there is MPC5xx ISA, there is VLE and and several other dialects. Some processors are doing those some doing others, some needs bit to signal if program runs VLE... just crazy chaos.
• whateverboat 2mo ago
  The huge number of companies building RISC-V chips and really crazy optimizations that they are doing in all kinds of spaces are a very real counterweight to your notion. And RISC-V is just starting here with shoestring design and fab budget. Wait till all engineering teams really adopt it like Tenstorrent and NextSilicon and so on.
  • pixelesque 2mo ago
    > really crazy optimizations that they are doing Any examples of this?
    • PunchyHamster 2mo ago
      There aren't ones that wouldn't be served better by ARM The improvement is entirely "we don't have to pay ARM"
      • zephen 2mo ago
        > There aren't ones that wouldn't be served better by ARM Sure there are. If you want to do weird and wacky stuff, try to do it with an ARM and see how fast you get shut down. > The improvement is entirely "we don't have to pay ARM" No, it's "we don't have to beg and grovel, or pay ARM."
        • sylware 2mo ago
          I guess this would be orders of magnitude more horrible with x86_64?
          • zephen 2mo ago
            Hard to know at this point. In the past ARM sued people for daring to think about implementing ARM compatible computers. (Even university research projects.) Of course, in the more distant past, AMD and Intel sued each other a lot. But there have been a dozen or so x86 market entrants. I think the competition has just been brutal. So, with either one, you could, of course, do a clean-sheet design and hope you don't get sued. Since ARM has historically only sold IP, they are incredibly jealous of their monopoly for that ISA. Of course, the flip side of it is that if you have enough money, and you beg and grovel enough, you can probably do what you want with their code. Except, of course, when you can't. Or rather, maybe you can, but they will try really hard to stop you. For example, Qualcomm, an architecture licensee who had purchased the rights to basically make whatever the fuck ARM they wanted, purchased a startup named Nuvia that also had an architecture license, and started using Nuvia's designs. ARM sued, just because. They were shut down in court, but the message is clear. They are very aggressive. Seriously, who needs that shit? Semiconductor market windows are tight enough as it is, and ARM has always acted like "Nice chip you've got there, buddy; shame if you haven't dotted your i's anc crossed your t's on the licensing." At least with Intel or AMD, you're probably only looking at patent lawsuits, and you could probably do a decent job on a low end machine with techniques that were known 20 years ago. You could do the same with ARM, of course, but they will sue you just because, to see if they can make you run out of money.
• gertop 2mo ago
  > Personally I don't see the benefit of this since you're going to have to recompile your software anyway The benefit is a unified toolchain. Make a chip, get the entire software toolchain for free. In the past if you made your own chip you had to write your own assembler, compiler, debugger, etc. Many manufacturers forked gcc but of course it's still a lot of work and the license isn't great (for them, not the user). This universal compiler toolchain is massive benefit for both the chip makers and the end user.
• phire 2mo ago
  The two authors also have a very different definition of what "high-end" means. Dmitry is talking about high-end application processors that you might find in a mid-range or better laptop, smartphone or server. Armstrong Subero seems to think that anything larger than a "dirt cheap microcontroller" is high-end. People shouldn't take this the wrong way, but the VexRISC-V cores in Baochip are not "high-end". They are basically as low-end as you can get while still meeting the modern definition of "application core". And that doesn't matter, because being high-end application SoC is not Baochip's design criteria. These cores are actually pretty decent for Baochip's criteria. The VexRISC-V are implementing the exact style of "classic-RISC" microarchitecture that RISC-V is optimised for. It's basically the optimal niche for RISC-V, before any of the problems start showing up. I don't think I've ever seen anyone express the opinion that RISC-V can't easily cover the "dirt cheap microcontroller" to "low-end application processor" range, even stretching up into "mid-range application processor". Just that it's really fighting an uphill battle if it ever wants to compete with high-end application processors (and that it's going to struggle in the low-range/mid-range application market because of that).
  • u1hcw9nx 2mo ago
    To add to what you said, I don't see any big issues with high-end prosessors and licenses. Anyone who spends $200 million to develop a completely new high-end processor microarchitecture every 3 to 5 years is not going to complain about an ARM license too much. You get freedom with $$.
    • LeFantome 2mo ago
      If you got “freedom with $$”, there would have been no ARM/Qualcomm lawsuit.
      • phire 2mo ago
        Softbank and ARM managed to burn a lot of good-will with that bullshit (it is a bad sign when I'm siding with Qualcomm), and all for nothing as they lost that lawsuit. But is generally true that the $$ buys architecture licensees quite a bit of freedom. Not as much freedom as they would get with something open like RISC-V, as ARM have strict rules around private ISA extensions (like how Apple doesn't publicly document AMX). But that extra control is generally a good thing for the health of the wider ARM ecosystem.
• andai 2mo ago
  Interesting. So I've seen a lot of reviews of RISC-V machines and they seem to be a decade or more behind in terms of performance. I always thought that was a case of "the tech is still catching up",[0] but it sounds like there are fundamental issues that prevent performant implementations? If so... I heard China was investing heavily in RISC-V, which implies that either they're going to have to settle for permanently crippled perf, or find a way around the issues. -- [0] Making chips is an extremely high tech process with decades of trial and error and proprietary secrets, so this would be the logical explanation to me regardless of architecture. But I'm not hardware guy, so I'd love to hear more about this!
  • phire 2mo ago
    No. Intel and AMD have proven that if you throw enough money at the problem, you can make fast microarchitectures despite a flawed ISA, and in many ways RISC-V is less flawed than x86. The things we are debating here are more along the lines of minor nitpicks. The main roadblock to the existence of fast RISC-V cores is the entrenchment of large x86 and arm ecosystems.
    • simcop2387 2mo ago
      > The main roadblock to the existence of fast RISC-V cores is the entrenchment of large x86 and arm ecosystems. I'd disagree with that, their existence and decades of a head start mean they've been much more well invested but that's one of the things we're starting to see change, even if it's because of what would appear to be political motivations. We're starting to see a lot of investment into it in China because it looks like it's a reasonable way for tech sovereignty against the x86 monopoly. They've got licenses to some older (not sure about newer) AMD processor designs, I think around Zen2 architecture, for one of their major manufacturing firms but that won't easily let them move forward since they've got to do a lot of work to keep it up with compatibility and performance for newer ISA additions and such. That's one of the reasons they've been subsiding development of LoongSong64 and RISC-V to the point where for a while the larger LoongSong64 cores were illegal to export to some countries[0]. And then you've got a lot of other companies building faster RISC-V cores, for yes more embedded style designs but not the usual traditional embedded designs either. You've got TensTorrent working on AI work loads with real hardware out there that at least for ML stuff can compete on inference if you can get your software to run on it, and then you've got Bolt doing similar for GPU workloads[1]. While both of those are closer to embedded since you're not going to use them as a desktop, they're still making really fast RISC-V cores that could be theoretically turned into a standard RVA23 core by adding the missing extensions to make it work. That's of course not trivial but the entrenchment of x86 and arm aren't quite as daunting as they might have originally seemed. It's still not as fast as I'd like, simply because I want to start seeing some RISC-V mini pcs get made that are fine for a daily driver office pc to happen. [0] https://www.tomshardware.com/news/china-bans-exports-of-its-loongson-cpus-to-russia-other-countries https://www.tomshardware.com/news/china-bans-exports-of-its-... [1] https://bolt.graphics/ https://bolt.graphics/
• K0balt 2mo ago
  First, im a big fan of what riscV has brought into the world; 0.50 cent processors with radios that can reach a kilometer, 8 cent MCUs that you can put anywhere because they are basically free, 8 dollar Linux computers, and 1 dollar WiFi nodes that can run reasonable applications. And also, the first application capable chip you can actually trust to be free of unpublished capabilities. RiscV is going to win despite its limitations, simply because they can be worked around freely, and the cost per core is zero. Every major company will be making their own flavor, because it’s the only way they can economically own the product of their work. Not many companies can be Qualcomm or Apple, but when a company invests millions in an architecture, they want it to be an asset on -their- balance sheet. It may not be the best starting point, but it’s the only journey that ends in ownership without starting from scratch. X86 had dominance for decades not because it’s the best architecture, but because it was the best choice. RiscV doesn’t have to be the best architecture to be the best choice for companies to build on.
  • random3 2mo ago
    Can you list the actual chips you’re referring to and additional sources to follow? I’ve finally started playing with ESP32 and recently getting curious about the smallest possible things out there. Also
    • kreelman 2mo ago
      Here's the CH32v003, https://github.com/openwch/ch32v003 https://github.com/openwch/ch32v003 These are pretty low end and are fairly available at low cost. Here's a youtube of someone talking through some of the the CH32 boards, https://www.youtube.com/watch?v=Kss6WQvJbRs https://www.youtube.com/watch?v=Kss6WQvJbRs He talks about them being the "10c/chip" chip. Then, there is the CH32v303 https://www.wch-ic.com/products/CH32V303.html https://www.wch-ic.com/products/CH32V303.html, which is the lower end of the chips that support minimal floating point and USB host/client. These ones are a bit more pricey, https://www.lcsc.com/product-detail/C5456849.html https://www.lcsc.com/product-detail/C5456849.html at $US1.72 each. The extra price is QFP64 (64 pins, quad flat pack) and more features on the chip, USB, CAN, V4F extension giving one instruction multiply and some floating point operations. Note that the fact that this chip uses an extension, V4F, for floating point (I think?) is part of the argument of Dmitry's piece on the RISC-V. The chip is pretty low price for a fair bit of power.
• brigade 2mo ago
  Well the original article is also about RISC-V isn't a great ISA for embedded either, and how that's supremely disappointing because there's no inherent reason why the designers couldn't have learned from decades of ISA research and made it suck even a little less. OP doesn't even defend the ISA committee (unlike HN, somehow...) As much as people complain about warts in other ISAs like x86, their design decisions made sense back when they were made (or at least, no one really knew better)
• MrBuddyCasino 2mo ago
  > I think he's kind of speaking past the original author. Thats being generous. He is spinning this into a 3rd world / 1st world social justice story, while ignoring the technical points dmitry made.
  • TMWNN 2mo ago
    I didn't get that impression. He talks about T&T (and places like that)'s inability to cheaply obtain components, but that's not the main point of his post
    • genxy 2mo ago
      Parent wanted to drop some anti-woke whistles because the author is black. Engineer from T&T makes a sound economic argument for the RISC-V ecosystem and suddenly it is "social justice". F that.
      • letmehelpyou 1mo ago
        [dead]
• bjackman 2mo ago
  > too much fragmentation to make binary distribution feasible Sorry I haven't actually read the original article so this is a bit of a driveby. But, I'm skeptical of this? Surely whichever cloud platform first offers RISC-V compute, the next cloud platforms will ship a CPU that's compatible. Probably they'll be RFTing the same CPU vendors and they won't need to coordinate explicitly for this to happen. Then everyone else building RISC-V servers will essentially be forced to align on the "AWS variant" or whatever. So yes you'll need a -cloud build of the distro you use but most people are already doing that and the cloud platforms are already providing the infra for distros to ship it (I assume they are also contributing to the -cloud distro builds directly). RISC-V laptops and phones I could see this being an issue but for server compute it feels like there's gonna be a Schelling point. (Actually, for phones can't Google just fix this by fiat?)
  • SuchAnonMuchWow 2mo ago
    I'm not completely sure, but are cloud versions of the distros actually recompiling the packages ? I though it was mostly: "select a minimal set of packages needed for docker and co", not "recompile all the packages you want in your distro".
    • bjackman 2mo ago
      Don't know actually, it might be I they are just putting cloud-init in, installing their VM agents, and maybe like tweaking the bootloader setup and kernel cmdline or something. But equally, they might be compiling it themselves so they don't have to trust distros' build farms so much. But anyway I don't think it matters. The hard part here is having a distro image supply chain, not compiling stuff. If they do need to start compiling loads of stuff they didn't before... They just need to add CPUs.
• twhitmore 2mo ago
  Good article, and I agree with the author's enthusiasm. However his points that "cheap parts are a great enabler" and "shipping costs are high to Trinidad and Tobago", while true, don't actually counter the OP's points that "feature determination needs to be universal" and "the instruction set is poorly designed". Others have said application authors will code to the specific platform, but that's not true of library authors -- they need portability. Why can the RISC-V team not get basic stuff like feature determination right? No matter how stupid the rest of the instruction set is, I'm with OP that the responsible individuals should retire from the committee.