Linus Torvalds says RISC-V will make the same mistakes as Arm and x86 - Page 1
Forum section: electronics / general

author: DiTBho
author_rank: Super Contributor
timestamp: August 01, 2024, 11:30:46 am
content: kernel 6.10Linus Torvalds saidRISC-V will make the same mistakes as Arm and x86Quoteumm ...

author: DiTBho
author_rank: Super Contributor
timestamp: August 01, 2024, 11:33:06 am
content: not sure what the "mistakes" are

author: brucehoult
author_rank: Super Contributor
timestamp: August 01, 2024, 12:29:26 pm
content: He doesn't know any, he's just hypothesising.Most RISC-V people are not "new" but are coming from long experience with x86 and/or Arm, and all major decisions are made with very wide consultation with domain experts in both industry and academia, not by half a dozen "new" people sitting around a table in a back room with the boss constantly asking them if they are done yet.If anything, the problem with the RISC-V ISA process is that it is too careful, too slow, for companies impatiently wanting vector/SIMD processing, hypervisor, crypto acceleration, etc etc.Individual companies are of course making mistakes, in designing their cores, in building an SoC around the cores, etc.The weird thing is that Arm is the opposite, pushing out all kinds of ISA extensions with almost no one picking them up. E.g. they published the SVE spec in January 2016 ... 8 1/2 years ago ... as an optional part of ARMv8.2-A but it's seen nearly zero uptake until it was forced on people in ARMv9. Virtually all commercial cores and chips are still on ARMv8.2-A ... without SVE ... and that includes things such as the RK3588 and whatever the chip is in the Pi 5 (both A76 cores). Meanwhile they published ARMv8.3-A (Oct 2016), ARMv8.4-A (Nov 2017), ARMv8.5-A (Sep 2018), ARMv8.6-A (Sep 2019), ARMv8.7-A (Sep 2020), ARMv8.8-A (sep 2021), ARMv8.9-A (Sep 2022). And starting in Sep 2019 the ARMv9-A series. As far as I know most of those have zero implementations, except by Apple (A12: ARMv8.3-A, A13: ARM8.4-A, A14/M1: ARM8.5-A, A15/A16/A17/M2/M3: ARMv8.6-A, M4 ARMv9.2-A). Qualcomm I believe was on ARMv8.2-A right up until a jump to ARMv9 with Snapdragon 7 Gen 1 and Snapdragon 8 Gen 1.

author: coppice
author_rank: Super Contributor
timestamp: August 01, 2024, 12:33:11 pm
content: Is he talking about poor instruction set and memory model types of choices, or the subtle stuff the RISC/V people are not going to be any more immune to, like information leaking/injection flaws?

author: madires
author_rank: Super Contributor
timestamp: August 01, 2024, 01:06:04 pm
content: I think it's about not seeing the big picture. Hardware and software people have different points of views. They need someone in between, i.e. someone who understands both worlds and helps to explain or manage the big picture.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 01, 2024, 09:24:33 pm
content: If it's about security holes due to speculative execution, for instance, sure. No reason chip designers would not make the same "mistakes". RISC-V is an ISA, not a microarchitecture.The kind of "mistakes" RISC-V will avoid is instruction sets that become absolute monsters with thousands of instructions and thus the need for excessively complex decoders and execution units.But one issue that is rampant is that due to the heavily modular ISA (which is also one of its strong points), RISC-V runs the risk of becoming very fragmented. So that over the years, any particular implementation may still be much leaner than a typical x86, but all existing extensions combined, the number of effective available instructions is not unlikely to largely exceed what ever went into an x86. After that it's only a question of marketing. Because to be used effectively, this modular approach also implies more reasonable designs with relatively specific uses, instead of making CPUs that will just contain as many features as is physically possible, which is what Intel/AMD are pretty much doing. Will RISC-V CPUs be immune to this feature inflation if they become as widespread as x86 ones for similar applications? I don't know. Marketing is a bitch.

author: coppice
author_rank: Super Contributor
timestamp: August 01, 2024, 10:14:48 pm
content: Quote from: SiliconWizard on August 01, 2024, 09:24:33 pmSo, you are worried that RISC/V will be just as fragmented as x86 currently is, with a dozen subsets of AVX512.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 02, 2024, 10:47:08 am
content: One interesting facet of the Linux kernel development is howusedirects the development. Someone working in the userspace needs a facility, and works with others to get such a facility included in the Linux kernel. Features are not developed first and then wait for users to find out about it; it works the other way around. In fact, when such facilities are developed, they often get modified until they are both useful (and not easily replicated in pure-userspace software) and maintainable within the kernel: any design will go through that wringer before getting included (except for drivers for new hardware that fit in to the existing driver framework).This means that Linus and other kernel developers are used to seeing interfaces used in novel ways, and also getting bit by hardware features that make some approaches impossible or overly complicated or annoyingly slow, simply because the hardware designers were not aware of those practical use cases and their patterns beforehand.I personally don't think that will ever change, because we already have reached the complexity levels where a single human being cannot master everything on the hardware side, nor everything on the kernel side, nor everything on the userspace side. I do believe this is what Linus was referring to, plus the tendency of people designing competing products or "reinventing the wheel" so to speak to fall into the same potholes their predecessors did, especially because they believe they know better than those predecessors (hubris, really). (It is especially funny in archaeology, where everything that does not have an immediate purpose to a modern-day human is a "religious artefact".)RISC-V is interesting, because although it is designed by "lot of people", it does not seem to suffer from "designed by committee".@brucehoultmight be able to enlighten us how they avoided that, but I suspect most of it is common purpose, hashing out a solution the slow way instead of giving in just to avoid a difficult discussion, and modularity.

author: DiTBho
author_rank: Super Contributor
timestamp: August 02, 2024, 01:27:22 pm
content: Quote from: Nominal Animal on August 02, 2024, 10:47:08 amI don't know, it's very complexIn my small way though... I can think about how things went in writing the myC machine level for the Arise-v2 architectureUsually you think about the ISA first - the hw-guys do it, who then have to implement it in hw -then you write the machine level of the compiler - the sw-guys who have to implement the toolchainIn my case I did exactly the opposite. That is, I modified the ISA several times to simplify my life as much as possible with monads &C.And the result? It's a "strange" thing, that probably nobody likes, except me.And this is also the real reason why these things are better done in large teams, with people who have different and much more specific skills.I don't know if it's possible to organize and manage, but this seems like a case where things converge toward a higher level of "suboptimal" the more brainstorming you do.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 02, 2024, 03:25:12 pm
content: Quote from: DiTBho on August 02, 2024, 01:27:22 pmYep, and the result probably included constructs you could not have imagined beforehand needing/being useful.Something as simple as choosing between LL/SC and CAS for atomics makes a huge implementation on the underlying hardware architecture. Ibelieve(but have no real experience in ISA design, so based only on my experience in coding for various architectures and approaches, and the bugs they have had) that LL/SC is simpler. The first multiprocessor/multicore environments I could really delve into were all x86-based, so my initial experience was with CAS and bus locking; it took me quite a while to see how LL/SC solves the same problems with fewer instructions in the instruction set.Any previous experience definitely causes some bias, until one gets enough experience to get a proper perspective. It does to me, at least; I've had to learn to compensate no matter how much it might 'sting'. I think it is like being in a valley, or on a mountain surrounded by other mountains, and exploring that biome in detail; then one morning waking up in a jungle or a sandy desert or salt flats. All together, there is way too much there to really delve into in a single lifetime. However, it is a difficult job to create and manage a large team of focused creative people; it is not an accident they say that managing software developers is like herding cats.Quote from: DiTBho on August 02, 2024, 01:27:22 pmFor sure; even I have done my best work in a team, not alone. It's just that you don't just slap together a team and expect excellent results of it; often it just collapses and key members leave. It takes somethingmore. A benevolent dictator is one possibility. I don't know what RISC-V folks did, but as I see it, they avoided the "design by committee" mismash/discontiguous results with little extra bits sprinkled here and there without any overall design. It isn't perfect, but what I've seen thus far, Ilike. How well it performs in practice, we'll see as the devices become more and more widely used. (I sometimes checkmarc.info mailing list archives for messages with risc-v in the subject.)

author: nctnico
author_rank: Super Contributor
timestamp: August 02, 2024, 03:30:30 pm
content: Quote from: DiTBho on August 01, 2024, 11:33:06 amThat would be good to find out. Otherwise it is just FUD

author: David Hess
author_rank: Super Contributor
timestamp: August 02, 2024, 08:22:51 pm
content: Quote from: brucehoult on August 01, 2024, 12:29:26 pmTorvalds has direct experience with these issues from his work at Transmeta, and from porting Linux between ISAs, especially newer ones, where all of the same mistakes were made.Quote from: coppice on August 01, 2024, 12:33:11 pmHe is referring to both, but mostly the former which impacts operation. Torvands has participated in many public discussions about this problem going back more than a decade.Going by memory, examples of problems include:Weak Memory Ordering - The strong memory ordering of X86 became one of its advantages.Page Size - Notice that Apple backed off from 64K pages, compromising on 16K pages. (1)Lack of Support for Unaligned AccessLack of Support for Shorter Datatypes - Alpha did this.(1) Page size relates to cache addressing, so a larger page size allows faster access of larger caches, but larger pages can cause other performance problems.

author: DiTBho
author_rank: Super Contributor
timestamp: August 03, 2024, 08:12:52 pm
content: Quote from: Nominal Animal on August 02, 2024, 03:25:12 pmLL/SC depends on the cache subsystem, and on MIPS R10K it's problematic, especially on non-coherent system.I remember serious problems supporting the Linux kernel on some R10K systems.We had to patch gcc, resulting in poor performance and problems.So, not only the architectures, but also the cache design are important.

author: David Hess
author_rank: Super Contributor
timestamp: August 03, 2024, 09:56:49 pm
content: Quote from: DiTBho on August 03, 2024, 08:12:52 pmLinus had software assisted cache coherency and software assisted page translation on his list of bad ideas also.

author: rhodges
author_rank: Frequent Contributor
timestamp: August 04, 2024, 12:02:04 am
content: Quote from: David Hess on August 03, 2024, 09:56:49 pmBut that made embedded MIPS so much FUN!And being able to use cached pointers or uncached just made the day so happy!

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 04, 2024, 12:40:19 am
content: Quote from: DiTBho on August 03, 2024, 08:12:52 pmAbsolutely.I was thinking more along the lines of inter-core bus locks (that x86 does), compared to a coherent cache subsystem with a relatively simple cache-level signal whenever a cacheline is transferred between two cores' or processors' caches, and handling the reservation on that cache line sensibly in hardware, if I was creating say an FPGA core. Adding DMA and priorities makes it a bit more funky, but I guess that is the reason DMA bypasses caches on so many Cortex-M cores. The bus lock sounds like a simple solution, but I've dealt with my share of complicated mutex deadlock scenarios with multiple concurrent cores to know it is a deceptively complex approach, with the same kind of sneaky butt-biting gotchas speculative execution has.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 04, 2024, 01:54:29 am
content: All this is not defined by any RISC-V spec, at least that I know of. And, yet. Maybe it will happen over time. Although you stilll want implementation flexibility as RISC-V is made for all kinds of targets and not just "big systems" with a Linux-like kernel.Memory ordering at this point is left to implementation, the ISA just providing fence instructions. Not unreasonable. Possibly a bit slippery, or unsufficiently fine-grained.

author: DiTBho
author_rank: Super Contributor
timestamp: August 04, 2024, 05:37:44 am
content: Quote from: Nominal Animal on August 04, 2024, 12:40:19 amOn a typical MIPS implementation of LL/SCCode:Load linked : LL rt, offset(rs)Store conditional: SC rt, offset(rs)To implement a memory semaphore, each LL/SC sequence has three sections:section1: The LL loads a word from memorysection2: A short sequence of instructions checks or modifies this wordsection3: The SC stores a new value into the memory word, unless the new value has been modified.If the word has not been modified, the store succeeds and a 1 is stored in the destination register.Otherwise the Store Conditional fails, memory is not modified, and a 0 is loaded into the destination registerIn section3, to understand if a word has been modified or not, the hw uses the cache dirty mechanism, and this creates quite a few problemsIndeed, section2 must not contain any of the events listed below, or the SC will fail:exceptionexecution of ERETload instructionstore instructionSYNC instructionCACHE instructionPREF instructionexternal intervention exclusive or invalidate to the secondary cache block containing the linked addressI recently implemented two Arise-v2 cores and wrote a very simple scheduler that works in SMP.I didn't implement LL/SC in the traditional MIPS way, also because I didn't implement the cache.Cache makes everything more complex, mutex and semaphore mechanisms should not rely on cache.

author: coppice
author_rank: Super Contributor
timestamp: August 04, 2024, 11:38:07 am
content: Quote from: SiliconWizard on August 04, 2024, 01:54:29 amNot quite knowing all the details of memory ordering has caused huge issues with other instruction sets. That has been partly due to the ordering logic changing over time, and partly that corner cases have not always been thoroughly documented in clear unambiguous language. Either way, it forces people to be cautious, and not squeeze out every last scrap of performance the hardware offers.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 04, 2024, 12:12:27 pm
content: In my opinion, all of the above makes Torvald's statement about expecting RISC-V implementors to repeat (some) past mistakes already seen on ARM and x86. It certainly fits what I know about human behaviour and historical precendent...The one big difference is the multitude of implementors, and how that changes the picture. I've described before how competition between open source projects (Apache – Nginx, and GCC – Clang, as two major examples) has revitalized them both. I don't exactly understand how that mechanism works, but it is possible the RISC-V implementors will learn from each others' mistakes earlier in the development cycles and fix them. I don't know enough of ARM core implementation history to compare it to that of x86 (and how much IP licensing prevented such "cross-pollination"), so I could be wrong here though.

author: coppice
author_rank: Super Contributor
timestamp: August 04, 2024, 12:37:06 pm
content: Quote from: Nominal Animal on August 04, 2024, 12:12:27 pmThe need for strong competition to achieve progress is an interesting dynamic. You might think that in a major open source project, like GCC or xfree86, competition between contributors might keep them on track. In practice I can't think of any strong examples where this has succeeded. Its appears more likely to descend into a fight. It seems we need competition between separate camps to keep things moving. Not 100 competing camps, like desktops, where nobody gets enough traction to have the resources they need, but 2, 3 or 4 good strong camps.

author: Just_another_Dave
author_rank: Regular Contributor
timestamp: August 04, 2024, 01:11:18 pm
content: In order to avoid those mistakes, it would be nice if he had listed them. Normally, EE that design processors (specially those who use RISC V) are more familiar with embedded systems than desktop computers, which might be one of the reasons for taking those decisions. In my experience, embedded development is significantly different from OS or desktop development, so those “mistakes” can be a better solution for some applications.The great thing about open source soft cores is that you can modify them while developing the software they’ll run, so they can be fixed. Reconfigurable ASIPs are also a good option for tuning hardware to your needs and they could help reducing risc v fragmentationHowever, I think that needing to manually write a compiler for your custom soft core may become a problem for risc v adoption. Programming languages get in and out of fashion so quickly that it can be difficult to provide compilers for enough of them. Linux previously just used C and assembly, which are usually the first languages supported, but now it is also programmed in rust (which requires a different compiler). It would be nice to be able to automatically generate compiler backends from VHDL or verilog, so the effort for migrating software to custom cores could be reduced

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 04, 2024, 01:48:52 pm
content: Quote from: Just_another_Dave on August 04, 2024, 01:11:18 pmWhy would you need to do that? You might need to tweak the code generation backend (seeLLVM RISC-VandGCC internals) for your RISC-V, but it is more likely you'll just specify the exact set of configuration options (corresponding to the RISC-V extensions) instead.I mean, you can look at AVR and ARM GCC backends for a comparison. Granted, there arefewerextensions there, but they still exist, especially on the ARM side for multiple-instruction single-data and DSP-like extensions.I would think that the existing support for various extensions means one should choose their soft core RISC-V ISA extensions based on a combination of need and existing support, which should limit divergence from the existing extensions. Then, as the frontend and optimizers are shared across programming languages and backends, software development doesn't need to worry about the ISA details.There is a risk of bad implementations that need software workarounds on certain implementations to work correctly. That would get really annoying real quick.

author: Just_another_Dave
author_rank: Regular Contributor
timestamp: August 04, 2024, 02:06:15 pm
content: Quote from: Nominal Animal on August 04, 2024, 01:48:52 pmAt least in designs in which I participated that used soft cores, it was quite common to add custom ISA extentions for accelerating specific operations that were important for that particular application. That’s one of the advantages of using soft-cores, but supporting those features from a compiler usually requires writing an specific backend for your custom processor for each compiler that needs to be supported, so having to use them from in-line assembly is not that weird. As a result I’ve seen embedded programs in which custom functions needed to be used for divisions, MAC operations, etc because the supported compilers weren’t able to optimize code as they weren’t aware of any of the available accelerators

author: brucehoult
author_rank: Super Contributor
timestamp: August 05, 2024, 02:52:25 am
content: Quote from: SiliconWizard on August 04, 2024, 01:54:29 amWait .. what?Memory ordering is something RISC-V didright, consulting a wide range of industry and academic subject matter experts to define the RISC-V memory ordering spec. It was published, as I recall, in late 2017, and is part of the ISA manual ratified in 2019: the RVWMO spec, and a informal appendix with explanatory material.https://five-embeddev.com/riscv-user-isa-manual/Priv-v1.12/rvwmo.htmlhttps://five-embeddev.com/riscv-user-isa-manual/Priv-v1.12/memory.html#sec:memorymodelexplanation

author: brucehoult
author_rank: Super Contributor
timestamp: August 05, 2024, 02:55:55 am
content: Quote from: coppice on August 04, 2024, 11:38:07 amThat is indeed true.And that is why FORMALLY defining memory ordering semantics was one of the FIRST things RISC-V did, seven years ago, before anyone even had any multi-core RISC-V processors.See my previous message.