6 ms·

RISC-V Origins and Architecture, Part 1

85 points by ChuckMcM 3y ago

cpeterso 3y ago
If you're curious about the origins of RISC-V, check out Andrew Waterman's PhD thesis "Design of the RISC-V Instruction Set Architecture" ("Why Develop a New Instruction Set?"). It's quite readable and has a nice comparison of ISA encodings of RISC-V, MIPS, SPARC, Alpha, ARMv7/8, Thumb, OpenRISC, and x86/x86-64. https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p...
dralley 3y ago
I don't get why the base ISA didn't include any atomic instructions. It's an annoying omission when even tiny embedded devices often have more than one core available. And single-core designs could just implement them as no-op, the silicon cost is miniscule.
- brucehoult 3y ago
  You can't implement AMOs as no-op! That code will fail horribly! You need (in a simple core [1]) a very un-RISC read/modify/write sequencer with bus lock. That's not cheap in silicon. Or trap and emulate using LR (which could be NOP) and SC (which could be a plain store) and a few other instructions. That's not fast. If you have that tiny embedded device with more than one core then you implement RV32IA properly, simple. And if you have a single core and no interrupts or DMA then implement RV32I and save a good bit of silicon. [1] big designs don't implement AMOs in the CPU core, but out in the peripherals, RAM controller, or cache controller. As far as the CPU core is concerned an AMO is a memory read that sends extra data (a constant and an operation code) out with the memory address.
cpeterso 3y ago
Any bets on when we we’ll see RISC-VI? And which aspects of RISC-V it will change, correcting mistakes or designs that didn’t scale to unanticipated computing environments or requirements?
- brucehoult 3y ago
  2100. Or never. IBM System/360 is still going strong after 60 years, with extensions not replacement. Only the 24 bit memory addresses were short-sighted. Motorola 68000 and ARM made the same mistake, 15 and 20 years later. Let's not even mention x86 memory addressing. RISC-V has that covered with 64 bit from the outset, and 128 bit addressing included in the planning. The basic RISC idea of separating load/store from arithmetic has stood the test of time for 60 years too, since 1964's CDC6600, the first supercomputer, and the fastest one for the rest of that decade. The Cray 1 in 1975 is also very much a RISC computer on the scalar side (plus vectors very similar to modern RISC-V V extension). Both of those machines had two instruction lengths just like current RISC-V: 15 and 30 bits on the CDC6600 and 16 and 32 bits on the Cray 1. RISC-V has had plans for future longer instructions, if necessary, from the outset. IBM 360 is actually very similar, with the same 2 bits in every instruction specifying whether the instruction is 16, 32, or 48 bits long. This makes very wide instruction decode simple -- 8 wide, 16 wide, even 32 wide if that is ever practical. Not quite as simple as doing the same thing on a completely fixed length ISA such as Aarch, but simple enough to not be a problem. Unlike x86. What else might want to change? More registers? That is easily handled with the planned-for 48 bit or 64 bit instruction formats. The long instructions can address all 64 or 256 or 1024 registers, while the 32 bit instructions can use only 32 of them, and the 16 bit instruction can use (mostly) only 8 of them. Or x86-style REX prefixes could be used. That works, but is worse for wide instruction decode unless the prefix itself indicates the full instruction length.
  - cpeterso 3y ago
    Thanks. It's interesting to see the commonality (path dependence?) of these ISAs and RISC-V's extensible design. I'm reminded of "How DEC Developed Alpha" (1992), an article describing how DEC designed the Alpha architecture to scale to handle a 1000-fold performance increase they anticipated over the next 25 years: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=144508 https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=144...
    - brucehoult 3y ago
pjmlp 3y ago
So first it has medium, now substack, oh well. At least the content is quite good.
ChuckMcM 3y ago
This is a great overview of the origin of the RISC-V project and I particularly like the history of instructions which tracks back to previous instructions that were "kind of" like the current instruction. I suspect this particular set of articles are assisting the RISC-V folks hold at bay the various patent lawsuits they are clearly being threatened with. One of the worst things about technology was that so many people focused on "If we own the road, we can charge EVERYONE a toll and get rich!" and so, so many, business plans were built around gaining exclusive control over key facets of technology. The idea that there could be an instruction set architecture (ISA) and related silicon implementations that anyone could use for free, is an existential threat to those who live on the margin generated by the licensing of their ISAs. If anything can derail ARM's growing influence, it will be this. The winners will be people like Apple with the resources to have their own chips fabbed with their own extensions and put into their own products which can run rings around people trying to use "generic" processors to do the same thing. Could signal a coming resurgence in demand for "computer architects" (old skool type :-))
- brucehoult 3y ago
  I don't know whether anyone has ever really threatened a patent lawsuit over the ISA, but it definitely does seem to be a good idea to document the origins of instructions, and that they are either so well known and obvious that they can't be patented, or else that they were patented and the patent has expired. Another protection is that the membership application for RISC-V International includes certification that RISC-V does not infringe on the applicant's own patents. With companies such as Intel, AMD, IBM, Marvell, Microchip, MIPS, nVIDIA, NXP, Qualcomm, Renesas, Samsung, Siemens, Sony, STM, Texas Instruments being members that covers a lot of ground. The base ISA (up to RV32GC, RV64GC) very deliberately breaks no new ground. It's just smoother, with known potholes filled in. Many of the optional extensions do break some new ground. The V extension has some unique features, though the basics are inspired by the Cray-1. RVWMO is based on experience gained with ARM and DEC Alpha memory ordering models, but fixing the problems -- and was actually designed by a world-wide group of academic and industry experts. Both of these are examples of something that simply would not be done as well by a small group of people inside a single company, working to a deadline.
unethical_ban 3y ago
>One of the greatest powers in the universe is grad-student naivety. When you don’t realise something is impossible, you try it anyway. A similar comment was in a dialogue in the Expanse series. I forget which character said it, but the gist was the same. It's a good lesson.
- guntars 3y ago
  As a general rule I think people underestimate how hard something is going to be. It’s a good thing though, otherwise they might not even start it.
unethical_ban 3y ago
As a totally ignorant person to CPU architecture, I do wonder what was wrong with OpenSPARC. I remember hearing about it back in college in the 2000s and thinking "wow, open source hardware! This is revolutionary!". I'm sure there is a good reason it didn't work/scale, but does anyone here know?
- johndoe0815 3y ago
  Andrew Waterman (Chief Engineer, Co-Founder of RISC-V and SiFive) describes the motivation for a new instruction set for RISC V in "Design of the RISC-V Instruction Set Architecture" (https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p...). The document contains a short discussion of the pros and cons of most architectures which were still somewhat popular at the time RISC V was designed (the Power/PPC is omitted) - MIPS, SPARC, Alpha, ARMv7/v8, OpenRISC and x86. Major points that count against SPARC in Waterman's view are: - SPARC register windows have significant power and area cost and complicate superscalar implementations - Branches use condition codes which result in more complexity for OOO implementations with register renaming - Load/store pair instructions also complicate implementations with register renaming (ARMv8 has introduced those, too) - Moves between the floating-point and integer register files must use the memory system as an intermediary - The only atomic memory operation is fetch-and-store, which is insufficient to implement many wait-free data structures The openly available SPARC implementations are either embedded-style cores (e.g. Gaisler's LEON3) or relatively specialized cores for highly parallel workloads such as web serving (T1 and T2). Regular Sun 4m/4u cores were not available in source form, but the SPARC license would have allowed alternative implementations. The license used to be available for a one-time fee of $99, but it seems SPARC can be used free and without royalties now, the $99 are an optional registration fee at SPARC International (https://sparc.org/faq/#q3 https://sparc.org/faq/#q3).
  - _chris_ 3y ago
    To add to this, Andrew et. al. at Berkeley built SPARC cores, so they were well aware of what it took to implement hardware to run SPARC software. I believe some of the really annoying challenges were at the system/privileged architecture level, including issues where off-the-shelf privileged software was either not obeying the specification or instead relied on undefined/underdefined corner cases. I believe RISCV's atomic read/modify/write CSR behavior was informed from some of these experiences.

85 points by ChuckMcM 3y ago

If you're curious about the origins of RISC-V, check out Andrew Waterman's PhD thesis "Design of the RISC-V Instruction Set Architecture" ("Why Develop a New Instruction Set?"). It's quite readable and has a nice comparison of ISA encodings of RISC-V, MIPS, SPARC, Alpha, ARMv7/8, Thumb, OpenRISC, and x86/x86-64. https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p...

dralley 3y ago

I don't get why the base ISA didn't include any atomic instructions. It's an annoying omission when even tiny embedded devices often have more than one core available. And single-core designs could just implement them as no-op, the silicon cost is miniscule.

brucehoult 3y ago
You can't implement AMOs as no-op! That code will fail horribly! You need (in a simple core [1]) a very un-RISC read/modify/write sequencer with bus lock. That's not cheap in silicon. Or trap and emulate using LR (which could be NOP) and SC (which could be a plain store) and a few other instructions. That's not fast. If you have that tiny embedded device with more than one core then you implement RV32IA properly, simple. And if you have a single core and no interrupts or DMA then implement RV32I and save a good bit of silicon. [1] big designs don't implement AMOs in the CPU core, but out in the peripherals, RAM controller, or cache controller. As far as the CPU core is concerned an AMO is a memory read that sends extra data (a constant and an operation code) out with the memory address.

cpeterso 3y ago

Any bets on when we we’ll see RISC-VI? And which aspects of RISC-V it will change, correcting mistakes or designs that didn’t scale to unanticipated computing environments or requirements?

brucehoult 3y ago
2100. Or never. IBM System/360 is still going strong after 60 years, with extensions not replacement. Only the 24 bit memory addresses were short-sighted. Motorola 68000 and ARM made the same mistake, 15 and 20 years later. Let's not even mention x86 memory addressing. RISC-V has that covered with 64 bit from the outset, and 128 bit addressing included in the planning. The basic RISC idea of separating load/store from arithmetic has stood the test of time for 60 years too, since 1964's CDC6600, the first supercomputer, and the fastest one for the rest of that decade. The Cray 1 in 1975 is also very much a RISC computer on the scalar side (plus vectors very similar to modern RISC-V V extension). Both of those machines had two instruction lengths just like current RISC-V: 15 and 30 bits on the CDC6600 and 16 and 32 bits on the Cray 1. RISC-V has had plans for future longer instructions, if necessary, from the outset. IBM 360 is actually very similar, with the same 2 bits in every instruction specifying whether the instruction is 16, 32, or 48 bits long. This makes very wide instruction decode simple -- 8 wide, 16 wide, even 32 wide if that is ever practical. Not quite as simple as doing the same thing on a completely fixed length ISA such as Aarch, but simple enough to not be a problem. Unlike x86. What else might want to change? More registers? That is easily handled with the planned-for 48 bit or 64 bit instruction formats. The long instructions can address all 64 or 256 or 1024 registers, while the 32 bit instructions can use only 32 of them, and the 16 bit instruction can use (mostly) only 8 of them. Or x86-style REX prefixes could be used. That works, but is worse for wide instruction decode unless the prefix itself indicates the full instruction length.
- cpeterso 3y ago
  Thanks. It's interesting to see the commonality (path dependence?) of these ISAs and RISC-V's extensible design. I'm reminded of "How DEC Developed Alpha" (1992), an article describing how DEC designed the Alpha architecture to scale to handle a 1000-fold performance increase they anticipated over the next 25 years: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=144508 https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=144...
  - brucehoult 3y ago

pjmlp 3y ago

So first it has medium, now substack, oh well. At least the content is quite good.

ChuckMcM 3y ago

This is a great overview of the origin of the RISC-V project and I particularly like the history of instructions which tracks back to previous instructions that were "kind of" like the current instruction. I suspect this particular set of articles are assisting the RISC-V folks hold at bay the various patent lawsuits they are clearly being threatened with. One of the worst things about technology was that so many people focused on "If we own the road, we can charge EVERYONE a toll and get rich!" and so, so many, business plans were built around gaining exclusive control over key facets of technology. The idea that there could be an instruction set architecture (ISA) and related silicon implementations that anyone could use for free, is an existential threat to those who live on the margin generated by the licensing of their ISAs. If anything can derail ARM's growing influence, it will be this. The winners will be people like Apple with the resources to have their own chips fabbed with their own extensions and put into their own products which can run rings around people trying to use "generic" processors to do the same thing. Could signal a coming resurgence in demand for "computer architects" (old skool type :-))

brucehoult 3y ago
I don't know whether anyone has ever really threatened a patent lawsuit over the ISA, but it definitely does seem to be a good idea to document the origins of instructions, and that they are either so well known and obvious that they can't be patented, or else that they were patented and the patent has expired. Another protection is that the membership application for RISC-V International includes certification that RISC-V does not infringe on the applicant's own patents. With companies such as Intel, AMD, IBM, Marvell, Microchip, MIPS, nVIDIA, NXP, Qualcomm, Renesas, Samsung, Siemens, Sony, STM, Texas Instruments being members that covers a lot of ground. The base ISA (up to RV32GC, RV64GC) very deliberately breaks no new ground. It's just smoother, with known potholes filled in. Many of the optional extensions do break some new ground. The V extension has some unique features, though the basics are inspired by the Cray-1. RVWMO is based on experience gained with ARM and DEC Alpha memory ordering models, but fixing the problems -- and was actually designed by a world-wide group of academic and industry experts. Both of these are examples of something that simply would not be done as well by a small group of people inside a single company, working to a deadline.

unethical_ban 3y ago

>One of the greatest powers in the universe is grad-student naivety. When you don’t realise something is impossible, you try it anyway. A similar comment was in a dialogue in the Expanse series. I forget which character said it, but the gist was the same. It's a good lesson.

guntars 3y ago
As a general rule I think people underestimate how hard something is going to be. It’s a good thing though, otherwise they might not even start it.

unethical_ban 3y ago

As a totally ignorant person to CPU architecture, I do wonder what was wrong with OpenSPARC. I remember hearing about it back in college in the 2000s and thinking "wow, open source hardware! This is revolutionary!". I'm sure there is a good reason it didn't work/scale, but does anyone here know?

johndoe0815 3y ago
Andrew Waterman (Chief Engineer, Co-Founder of RISC-V and SiFive) describes the motivation for a new instruction set for RISC V in "Design of the RISC-V Instruction Set Architecture" (https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p...). The document contains a short discussion of the pros and cons of most architectures which were still somewhat popular at the time RISC V was designed (the Power/PPC is omitted) - MIPS, SPARC, Alpha, ARMv7/v8, OpenRISC and x86. Major points that count against SPARC in Waterman's view are: - SPARC register windows have significant power and area cost and complicate superscalar implementations - Branches use condition codes which result in more complexity for OOO implementations with register renaming - Load/store pair instructions also complicate implementations with register renaming (ARMv8 has introduced those, too) - Moves between the floating-point and integer register files must use the memory system as an intermediary - The only atomic memory operation is fetch-and-store, which is insufficient to implement many wait-free data structures The openly available SPARC implementations are either embedded-style cores (e.g. Gaisler's LEON3) or relatively specialized cores for highly parallel workloads such as web serving (T1 and T2). Regular Sun 4m/4u cores were not available in source form, but the SPARC license would have allowed alternative implementations. The license used to be available for a one-time fee of $99, but it seems SPARC can be used free and without royalties now, the $99 are an optional registration fee at SPARC International (https://sparc.org/faq/#q3 https://sparc.org/faq/#q3).
- _chris_ 3y ago
  To add to this, Andrew et. al. at Berkeley built SPARC cores, so they were well aware of what it took to implement hardware to run SPARC software. I believe some of the really annoying challenges were at the system/privileged architecture level, including issues where off-the-shelf privileged software was either not obeying the specification or instead relied on undefined/underdefined corner cases. I believe RISCV's atomic read/modify/write CSR behavior was informed from some of these experiences.