Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software Hardware Linux

Linus Torvalds Says RISC-V Will Make the Same Mistakes As ARM and x86 (tomshardware.com) 73

Posted by BeauHD from the stumbles-expected dept.
Jowi Morales reports via Tom's Hardware: There's a vast difference between hardware and software developers, which opens up pitfalls for those trying to coordinate the two teams. Arm and x86 researchers encountered it years ago -- and Linus Torvalds, the creator of Linux, fears RISC-V development may fall into the same chasm again. "Even when you do hardware design in a more open manner, hardware people are different enough from software people [that] there's a fairly big gulf between the Verilog and even the kernel, much less higher up the stack where you are working in what [is] so far away from the hardware that you really have no idea how the hardware works," he said (video here). "So, it's really hard to kind of work across this very wide gulf of things and I suspect the hardware designers, some of them have some overlap, but they will learn by doing mistakes -- all the same mistakes that have been done before." [...]

"They'll have all the same issues we have on the Arm side and that x86 had before them," he says. "It will take a few generations for them to say, 'Oh, we didn't think about that,' because they have new people involved." But even if RISC-V development is still expected to make many mistakes, he also said it will be much easier to develop the hardware now. Linus says, "It took a few decades to really get to the point where Arm and x86 are competing on fairly equal ground because there was al this software that was fairly PC-centric and that has passed. That will make it easier for new architectures like RISC-V to then come in."
This discussion has been archived. No new comments can be posted.

Linus Torvalds Says RISC-V Will Make the Same Mistakes As ARM and x86 More

Linus Torvalds Says RISC-V Will Make the Same Mistakes As ARM and x86

Comments Filter:

  • You don't need to look at hardware to see this (Score:5, Interesting)

    by ffkom ( 3519199 ) on Friday July 12, 2024 @04:27PM (#64622099)
    Even in between software abstraction layers, like "back-end"/"front-end", or "API endpoint"/"application", one can watch the same stupid mistakes being repeated over and over again, even within one company, because nobody likes to consult with the experienced grumpy old men, who have seen it all happening before.

    • Or network layers that ignore how high level software expects to operate.

      • Re: (Score:2)

        by Entrope ( 68843 )

        I think you mean "high level software that ignores unavoidable trade-offs in how network protocols can work". (No, you got chocolate in my peanut butter!)

    • Re:You don't need to look at hardware to see this (Score:5, Insightful)

      by fahrbot-bot ( 874524 ) on Friday July 12, 2024 @05:12PM (#64622165)

      ... because nobody likes to consult with the experienced grumpy old men, who have seen it all happening before.

      Assuming they haven't been laid off or encouraged to retire in favor of younger/cheaper employees ...

    • The fundamental problem here is that everyone thinks RISC-V is open

      It is, but only the ISA. The actual core is not open. The ISA just tells you what the core will do when you present it with certain bit patterns that we give names to.

      The RISC-V cores are not necessarily open. You can take the ISA and design your own core that implements the RISC-V instruction set. I've seen cores implemented with TTL chips to very fancy cores used in higher end machines, usually using a SiFive chip.

      SiFive has some of the most performant chips out there, but their core isn't open, so it isn't like you can take their core and tweak it to make it better. I think they will license the core to you for an ASIC, but that's about it.

      Meanwhile, the open cores are generally so-so - not because of their implementation method (most are on FPGAs, which limits your speeds) but architecture wise.

      Of course, what I see happening is a company like SiFive being dominant in the RISC-V space because if you need performance, you go with them, and they'll be like ARM offering the core designs everyone uses.

      I recently had a conversation with some architects at my company who were considering RISC-V. I asked them what core they were planning to go with and they looked at me oddly - they assumed with RISC-V, being open, that they could just plop something on an ASIC and be done with it. I told them no, what's open is the ISA. You either need to design your own core, or license a core from someone (like we do with ARM). They all assumed that by adopting RISC-V they'd never have to pay license fees again - you'd get a full design and everything that you tweak, like the Linux kernel.

      So yeah, everyone's going to fall into the same traps over and over again. When SiFive implements speculative execution on their cores, I would expect Spectre and Meltdown to apply to those cores. Of course, a key problem is the people who design ASICs for a living make very good money and generally their knowledge is so specialized it's not something that's shared other than by working together. After all, ASICs cost millions of spin out, and simulation and design another few million dollars. The closest anyone "normal" can get to do it is using an FPGA board. But that's around the same scale of going from "hello, world" to an OS kernel.

      • An open spec and free license is a step up from the alternatives we have dealt with for decades. And there are open core available for RISC-V, even if they aren't the fastest, cheapest, or most readily available.

        This situation has parallels in the software world. Some applications are closed and some are open source. You can use the GIMP, which is inferior in many ways, or you can use something closed from an abusive company like Adobe to get your work done.

        It is theoretically possible to build a completely

      • There are reasonably advanced open source RISC-V cores available.
        https://github.com/XUANTIE-RV/... [github.com]

        That is the T-head Xuantie 910 RISC-V core's Verilog. This is a 12-stage, out of order, dual-issue, 64-bit RISC-V core.
        You can also buy chips with it fairly cheap.

    • nobody likes to consult with the experienced grumpy old men

      Except in this case, the grumpy old man is Turning Award winner David Patterson. In addition to RISC-V, he also led the teams that designed RISC-1, RISC-2, RISC-3, and RISC-4.

      • Or whatever award it was he wonâ¦.

      • And MIPS which was one of the early RISC architectures and a major competitor for X86 and ARM and SPARC and POWER and Alpha back in the 90s. mIPS was used to render Jurassic Park and Terminator 2 and is still widely used in routers. RISC-V is basically the chip where the experienced grumpy old-timer looked at his design for MIPS, took the lessons learned and fixed his old mistakes.

        It is. It like RISC-V is new. It is a redesign of the original RISC

        • 64-bit mode on ARM is quite a bit more MIPS-like than it is ARM-like. It really blurred the lines for me when I had to switch over my development.

          SPARC adopted some interesting aspects of the early RISC projects that were abandoned by some others. I think technically it was a superior architecture. But Sun and eventually Oracle bungled the marketing side of things.

          • How in the fuck do you figure?

            Was it all the delay slots everywhere? Wait- no. Don't have those.

            • Re: (Score:3)

              by _merlin ( 160982 )

              AArch64 is more like PowerPC than MIPS, but either way, it's not very ARM-like. It has a bunch o

              • It's doubled the general-purpose registers to 32 (like PowerPC/MIPS/SPARC, as opposed to ARM's 16).
              • Unlike MIPS/SPARC, it doesn't have a dedicated zero register - like PowerPC, there's a register that acts as a constant zero for some instructions but not others.
              • Like x86-64, 32-bit operations zero the upper half of the destination register (PowerPC/MIPS/SPARC always operate on the whole 64-bit register).
              • AArch64
              • Yes, it's not very arm-like at all. Especially since the removal of the predicates from non-branch instructions (sad).
                It's still *nothing* like MIPS.

                I love the "doubled general purpose registers", as if that's a defining ISA characteristic.
                x86-64 doesn't have a general-purpose PC, either.
                Sure, it shares some features with PPC, some with MISP (but really, not really), and some with x86-64.

                Really, it's its own thing entirely.
                • Note, In no way was I arguing that aarch64 "is arm-like".
                  I was criticizing the idea that it's MIPS-like, which is frankly fucking absurd.
                  I've been writing MIPS and arm assembly for a decade and a half.
                  aarch64 made arm a lot less fun to play with for me, but that's ok. I understand why they did it. It's time for the ISA to grow up and be a big boy ISA.
                  MIPS/64 is going to ride that original RISC idea right to the grave where that ISA is buried.

                  MIPS held a commanding lead in small routing devices like SO

      • Turning Award winner David Patterson.

        "Turing Award", please.

    • Re: (Score:2, Troll)

      by thegarbz ( 1787294 )

      because nobody likes to consult with the experienced grumpy old men, who have seen it all happening before.

      The big problem is that it's the experienced grumpy old men causing this. In my professional experience (not in IT) experienced grumpy old men fall into two categories with a virtually 50/50 chance:

      1. Experienced grumpy man upset that kids are repeating mistakes, whom if you consult can give you a solution that fits with modern ways of working to the betterment of all (modern tech + not repeating mistakes).

      2. Experienced grump man who hasn't seen the failures of the past and declared the modern world unfit

      • So... instead of risking the loss of an hour or two and some disrespect, it's better to reinvent the bicycle? A little humility would pay off.

        • I implied nothing of the sort, but yes you're entirely correct. The opposite of experienced grumpy old men are inexperienced young carefree ... women technically... ignore the gender here ;-). Someone young and inexperienced repeating the same mistakes is equally inexperienced with interpersonal communication.

          I can apply the 50/50 rule to young people in my career as well, half of them are actively afraid of talking to some people. Humility in a professional setting is a learned skill.

      • I agree with you 100%. Last compan some grumpy old man still uses unreliable XFS instead of anything newer cause that’s the wa it was in1995. And then lost customer data.

    • How about they talk to FAILED software projects like the micro kernel people? It's better to push most everything outside the the kernel but nobody succeeds in this because of the performance hit ... which hardware could address! they added VM acceleration features...

      We take speed hits in many other areas which we allow but not in this area.... why not? Me, I like Multics abilities... how about exploring that too? would be nice if one could just slap cpus, ram, (and cpu upgrades) etc together at runtime

  • Too bad it didn't work out for transmeta.

    We have a different meta into hardware these days ðY£, very different

    • Right. I'm sure RISC-V folks would be open to suggestions.

      But hardware folks /also/ understand some things kernel folks don't. It goes both ways.

      • Re:Arguably as long as it's not the same as transm (Score:5, Interesting)

        by ffkom ( 3519199 ) on Friday July 12, 2024 @05:21PM (#64622183)

        But hardware folks /also/ understand some things kernel folks don't. It goes both ways.

        Absolutely! Spending time programming assembler, then VHDL, then assembler again, makes one really see things from a different perspective. I for one would argue that designers of new hardware or (low-level-)software architecture should definitely spend some time "on the other side" to understand it better.

  • Single owner of hardware, software and the trade-offs between them, viewing the whole system, well, "systemically".

    • Also in the case of Apple, they are not trying to solve general computing problems for many use cases. Apple makes CPU designs for their devices. RISC-V has two examples to learn from.

  • Without ARM, x86 might have completely taken over. But ARM didn't start in an x86 exclusive world and at no point did it even become only x86 and ARM. It started in and there is still are multiple architectures. The mainstream might not know them well but the hardware and kernel people do. All the problems that ARM faced are still there to trip up RISC-V and the solutions employed by ARM aren't really special or unique.

    • The uncomfortable truth of it, is that arm's path to success really followed a decade of making it more like modern x86 processors.
      With aarch64 they have abandoned some of the coolest aspects of their ISA.

  • Making a new CPU is difficult, but with things like Cadence's Palladium and Synopsys's ZeBu, you can get the ISA and the main parts of the CPU coded, then run it in the simulator. It may take days to weeks for it to boot a Linux kernel... but it can. With the tools that Synopsys and Cadence provide, life is a lot easier for CPU design than in the past, where one can let a well-debugged AI handle floor plan, layout, and other items. This doesn't mean it is easy to make a CPU, but it means the development

    • Re: (Score:1)

      by tlhIngan ( 30335 )

      Making a new CPU is difficult, but with things like Cadence's Palladium and Synopsys's ZeBu, you can get the ISA and the main parts of the CPU coded, then run it in the simulator. It may take days to weeks for it to boot a Linux kernel... but it can. With the tools that Synopsys and Cadence provide, life is a lot easier for CPU design than in the past, where one can let a well-debugged AI handle floor plan, layout, and other items. This doesn't mean it is easy to make a CPU, but it means the development cyc

      • The fact that RISC-V is free and doesn't require CPU core payments are likely what will get them in the running. Especially in China, where from what I see with new SBCs coming out all the time, it only is a matter of time before Chinese companies hammer out some type of standard, with SMIC doing their chip fabrication. In the past, I'm pretty sure they were going to go on Zhaoxin style x86 CPUs, but with Centaur gone, the goose that laid the magic eggs there is gone, so it is up to the Chinese engineers

      • I began working with arm back in the arm7 days.
        No standardized bus, or even standardized MMU on the parts that had it.

        It was absolutely the single largest factor that kept it back- every singe arm CPU, that while having the same ISA- had basically nothing else in common. They each had a manufacturer proprietary bus, and a manufacturer proprietary memory and peripheral mapping. I loved it at the time, because it felt so raw, but it quickly became annoying.

  • How is this even news? (Score:3)

    by Casandro ( 751346 ) on Saturday July 13, 2024 @01:14AM (#64622609)

    I've just watched the Interview. There's very little content past the headline. Linus thinks the RISC-V World will make the same mistakes other ecosystems did before. He doesn't go into details or anything.
    However it is obvious that it is making at least some mistakes. For example, unlike x86, OS-Images are non portable. You cannot just get an SD-Card with an operating system for a Raspberry PI and boot it up in any other ARM-based computer. Same goes for RISC-V.

    • I also wanted the article to at least list a couple of the mistakes Linus think will be repeated.

      I thought it was the programmers who should code for the hardware and not the hardware constructors who should build for the software that will be run on it.

      • I thought it was the programmers who should code for the hardware and not the hardware constructors who should build for the software that will be run on it.

        Surely both is best? I remember that during the VAX/VMS design process, hardware and software people worked closely together and iterated design proposals.

        That's the main reason it was called VAX/VMS - the name included both the hardware architecture and the operating system.

    • Yes, underwhelming. I will go ahead and speculate that Linus is mainly thinking about side channel attacks and the speculative execution designs that facilitate them. Other obvious pitfalls, e.g., broken metavirtualization, I hope will be avoided. It's not like IBM didn't get those sorted back in the 70s.

  • For anyone seriously interested in sharing previous experience, there *are* RISC-V working groups e.g. on safety (https://lists.riscv.org/g/sig-safety/) , microarchitectural side channels (https://lists.riscv.org/g/sig-uarch-side-channels) etc.

  • On the plus side, as soon as the less experienced hardware people find out they have a problem, the smarter ones can look up history to find what works as a fix.

  • Lame that Linus did not mention any specific issues. I can speculate (... virtualized interrupt gating??? ...) but why? Linus could have just rattled off a few. Or was he just fishing? Linus does that from time to time, master of rhetoric that he is.

    • ...tagging on. He could be thinking about side channel attacks, currently bedeviling every major CPU architecture. And frankly, I'm ok with RISC-V not being perfectly airtight against Spectre in its initial incarnations, if it delivers the performance. Just don't be a whole lot worse than AMD, please, and lets keep the bad guys out by improving defenses at the browser level. And of course, taking a pass on closed source binaries, particularly from untrusted sources like Microsoft.

Slashdot Top Deals

Think of it! With VLSI we can pack 100 ENIACs in 1 sq. cm.!

Close