12 ms·

RISC-V Stumbling Blocks

123 points by lelf 7y ago

thethirdone 7y ago
I wrote an educational simulator for RISC-V [0] two and a half years ago and the documentation for RISC-V has gotten marginally better. There a fair number of universities using RISC-V to teach that have published their slides and such publicly [1]. However those is not super helpful for people who already understand assembly and computer architecture reasonably well. The best way I can see to get up to speed is to read some example demonstrating each instruction. I have thought about a site that has a table of instructions that links to an online simulator [2] to let you step through an example detailing edge cases. The best source of simple assembly examples I know of would be the tests from my project [3]. Though those could be a lot more helpful for a human reading them. As for simulators, there are quite a few. The website lists a bunch [4]. I am not sure how many would support any kind of machine mode memory mapping though. [0]: https://github.com/TheThirdOne/rars https://github.com/TheThirdOne/rars [1]: https://github.com/riscv/riscv-teach https://github.com/riscv/riscv-teach [2]: https://venus.cs61c.org/ https://venus.cs61c.org/ [3]: https://github.com/TheThirdOne/rars/tree/696ef9ed82285f0a73d80370c18be5524e95f0db/test https://github.com/TheThirdOne/rars/tree/696ef9ed82285f0a73d... [4]: https://riscv.org/software-status/ https://riscv.org/software-status/
ncmncm 7y ago
The riscv people missed some serious opportunities for fundamental improvements, probably the last such opportunity in this generation. Perhaps the biggest was that the comparison instruction should have had the condition being looked for in the instruction, and put the result in register 0 as a 0 or ~0 (= -1). Register renaming can then carry it through pipelines. Subsequent instructions may AND register 0 with other values, or subtract it from them, avoiding frequently mispredicted branches.
- thethirdone 7y ago
  I am not quite understanding the missed improvement you are talking about. Are you saying that instead of (or in addition to) "branch if equal", "branch if less than", etc there should be a "set if equal", "set if less than", etc? In case you are, there is a "set if less than" instruction. The floating point extension does have a "set if equal" instruction despite there not being an integer equivalent. Alternatively if you are complaining about 1 representing True rather than ~0, I don't think that matters much from a technical POV.
  - ncmncm 7y ago
    The condition codes from comparison operations have always been a problem for out-of-order execution units. Feeding the result directly to the register bank sidesteps the problem. Conditional-move instructions have also been a problem, which this also sidesteps. Branch-register-zero and -nonzero instructions complete the set. The extra step to get a comparison result into a register, and another to extend it to the whole register, is an inefficiency I would prefer to leave behind.
    - jleahy 7y ago
      It's a single instruction to then subtract 1 from the result of SLT/SLTI, which then gives you 0xffffffff or 0x00000000 rather than 0 or 1, which you can use as a mask. RISC-V was designed to be a good target for a C compiler, given that's what people almost always need. Compilers frequently see code line `int x = (a > b)` and SLT is perfect for that. Compilers don't do clever masking tricks to avoid branches, in general (there are a few hard-coded tricks like divide by signed constant).
      - ncmncm 7y ago
        In other words, two more instructions, instead of zero. That compilers fail to do clever masking tricks to avoid branches frequently results in 2x slower programs.
        avianes 7y ago
        No, as jleahy said, it cost a single instruction to transform 0 to 0b00..00 and 1 to 0b11..11 - SUB X, $0, X. And your proposal - using the zero register as a flag register - breaks way more micro-optimizations (like the simple ones described in "The RISC-V Reader" book) than it allows
      - bonzini 7y ago
        > Compilers don't do clever masking tricks to avoid branches, in general They actually do a lot of such tricks. Check out the GCC sources, for example tree-ssa-phiopt.c[1] and ifcvt.c[2] [1] https://github.com/gcc-mirror/gcc/blob/master/gcc/tree-ssa-phiopt.c https://github.com/gcc-mirror/gcc/blob/master/gcc/tree-ssa-p... [2] https://github.com/gcc-mirror/gcc/blob/master/gcc/ifcvt.c https://github.com/gcc-mirror/gcc/blob/master/gcc/ifcvt.c
- rwmj 7y ago
  RISC-V is meant to be a simple, unsurprising, boring architecture, with any clever stuff (such as macro op fusion) being done at the microarchitecture level. It's not a project for researching new architectures.
  - beefhash 7y ago
    I really wish it was just one tiny less bit simple. The RISC-V spec doesn't specify that multiplication instructions (if implemented) need to be constant-time. Which means RISC-V cores will need stupid hacks for cryptography like these: https://bearssl.org/ctmul.html https://bearssl.org/ctmul.html
    - rwmj 7y ago
      It could be added in the future as a simple extension. (In fact I found at least two proposed crypto extensions with a simple search although neither mentions constant-time ops from a quick scan). There's a considerable penalty for all implementations if every multiply implementation has to be constant time.
      - ncmncm 7y ago
        That is another problem. The "optional extensions" have all the useful instructions in them, but typically just a couple of the instructions in each extension would provide most of its value. So, I don't get popcount because it's in the bitmanip extension along with 10M transistors' worth of clever stuff I don't need. Similarly, each of the other extension sets. It would be much more useful to define slices through all the defined ones, so you get either the absolute minimum core instructions, or add just the coremost of each extension set, or a more comfortable subset of each, or half of each, spiraling outward as transistor budget grows.
        rwmj 7y ago
        10 million transistors is a tenth of a square millimeter on current nodes, but that aside you really wouldn't want such a complicated system of "sub-extensions" because it would be a nightmare to write software for. Either the software would only work for very specific sub-extension mixes, or would require layers of ifuncs to deal with all combinations of missing sub-extension features. The current system of fairly granular extensions, a useful base architecture, and profiles defining what extensions are guaranteed for particular application classes (eg "Unix server") is a nice compromise between extensibility and software/distro complexity.
Quequau 7y ago
This: > If you want to do any OS work, you need a system that implements the Privileged ISA. Supporting the Privileged ISA is synonymous to being able to run UNIX-like systems, because it brings user-/supervisor-mode distinction and paging. Working on real hardware is generally preferred to working in emulators, because the code eventually has to run on metal anyway and emulators can be too forgiving for certain classes of problems. There is a plethora of RISC-V microcontrollers for a couple of dollars that all don’t support the Privileged ISA. At the time of writing, the only board you can buy that does support it is the $1000 HiFive Unleased, which was beyond my “I just want to play around with this” budget. Suggests to me that it's at least part of why Stephen Marz [0] isn't trying to target a specific board with his project (which has been posted here a few times and I'm sorta following along). That pretty much kills most of the interest in RISC-V that I had in me. I guess I'll wait a few more years and check back again later. [0]: https://osblog.stephenmarz.com/index.html https://osblog.stephenmarz.com/index.html
- pjc50 7y ago
  For some reason, people have a fantasy that RISC-V is going to give them a sub-dollar microcontroller that runs Linux, rather than being like ARM where "microcontroller" and "Linux capable" and "server grade" are three entirely different market segments.
  - rjsw 7y ago
    I have several ARM dev boards and am thinking of getting a PinePhone, am happy to pay upto $200 for something to play with but not $1000. The HiFive Unleashed is interesting in that it has a lot more RAM than cheap ARM dev boards, for the same money though I could get a HoneyComb LX2K ARM system.
    - floatboth 7y ago
      Not for the same money, for much cheaper. HiFive Unleashed is $1000 for the board with onboard RAM… but it does not have PCIe onboard, so if you want that, you could pay $2000 extra (!!) for the "HiFive Unleashed Expansion Board" that has a giant FPGA that has a PCIe root complex programmed on it. HoneyComb LX2K is $750 for the board with 64GB eMMC + bring your own SODIMMs for RAM. SolidRun also offers the MACCHIATObin for $339. 4-core A72 + 4GB full-size DIMM included. (The single-channel-ness of the RAM is not good for performance, but you can install a big 16GB DIMM no problem.) Both the LX2K and the mcbin have PCIe of course :)
Annatar 7y ago
"While reading the rest of this post, please keep in mind: RISC-V is simple!" That's either a lie, or the author is severely traumatized from coding on x86 and is suffering from the Stockholm syndrome. Poor author; I feel sorry for the bloke. Code on UltraSPARC or MC68000 family of processors and then you will know what simple means. The instruction set of RISC-V is insane, absolutely insane.
- legulere 7y ago
  As I am someone who has never seen assembly from those languages, can you explain to me what is insane about RISC-V?
  - Annatar 7y ago
    By definition, RISC stands for "reduced instruction set computer". And RISC-V exposes its internals so it has way more instructions than a conventional CISC processor, a lot of which deal with its internal states. Here is a good example[1]: For general signed addition, three additional instructions after the addition are required, leveraging the observation that the sum should be less than one of the operands if and only if the other operand is negative. add t0, t1, t2 slti t3, t2, 0 slt t4, t0, t1 bne t3, t4, overflow ...good luck programming this insane design with anything other than a high level language compiler. [1] https://riscv.org/specifications/ https://riscv.org/specifications/
    - avianes 7y ago
      > And RISC-V exposes its internals But your example shows no internal states exposure, it's just arithmetic to detect overflow. What are you trying to show ?
    - Symmetry 7y ago
      Generally, the "reduced instruction set" in RISC refers to how many instructions are available to the programmer, i.e. not many, rather than the larger number of instructions it then takes to accomplish anything. And the difficulty isn't really about exposing the internals, this isn't like a branch delay slot for instance. It's about making the relationship between instructions conceptually simple where there's always up to 2 inputs and up to one output. That doesn't help much in cases where the processor is doing something close to what the instructions are saying but it makes the simplest possible out of order processor, where the internals diverge wildly from the ISA, much easier to create. EDIT: Also, the using C and compiling rather than doing assembly by hand is really a fundamental part of the whole RISC philosophy and RISC-V is just a more extreme form of that.
gumby 7y ago
TBF Intel's x86 documentation has evolved incrementally over the last 40+ years. And it comes from an older tradition of engineering documentation which seems to have fallen by the wayside over the last 20 years or so. At an extreme, some ARM vendors like Mediatek don't even produce data sheets, as their model is one of chip+consulting.
jhallenworld 7y ago
I just tried the Project Trellis open source FPGA tool chain for RISC-V. I was forced into it: a few years ago I bought the Lattice ECP5-5G Versa Dev kit (on sale at the time for $99, $200 now I think). The Lattice tools for the FPGA on this board requires a license. Well the license ran out, and I don't want to pay $900 for a Diamond license. Anyway, I got this example from Project Trellis to work on this board. It uses this "PICO RISC-V" (the entire CPU is in a single Verilog file): https://github.com/SymbiFlow/prjtrellis/tree/master/examples/picorv32_versa5g https://github.com/SymbiFlow/prjtrellis/tree/master/examples... I think it would be straightforward to build a Linux capable RISC-V system for this board using this free tool chain. The board has SDRAM, FTDI UART and SPI-flash. It does not have an SD slot, but maybe could be wired in with the expansion headers. This ULX3S board also looks promissing, but is not available yet: https://www.crowdsupply.com/radiona/ulx3s https://www.crowdsupply.com/radiona/ulx3s What's very cool is that low end ECP5 FPGAs are around $5. I think RISC-V on an ECP5 with LCD touch interface might be the cheapest available option for a Linux microcontroller with a touch LCD interface. By available, I mean where you can easily buy the chips on mainstream distributors (otherwise it would for sure be some AllWinner chip).
- kersny 7y ago
  A RISC-V linux system for the ECP5 can be built with the FOSS toolchain using vexriscv and litex: https://github.com/litex-hub/linux-on-litex-vexriscv https://github.com/litex-hub/linux-on-litex-vexriscv also, step by step using a different core (rocket): https://insights.sei.cmu.edu/sei_blog/2019/10/how-to-build-a-trustworthy-freelibre-linux-capable-64-bit-risc-v-computer.html https://insights.sei.cmu.edu/sei_blog/2019/10/how-to-build-a...
  - jhallenworld 7y ago
    I'm amazed to see the preferred toolchain for LiteX for ECP5 listed as "Yosys/Trellis/Nextpnr" (and vendor proprietary tools for the other families). The rocket core mentions 102% of space used of an 85K LUT FPGA and having to deal with it. I wonder which core is using so much space? I have more experience with vendor soft cores, and they would use much less..

123 points by lelf 7y ago

I wrote an educational simulator for RISC-V [0] two and a half years ago and the documentation for RISC-V has gotten marginally better. There a fair number of universities using RISC-V to teach that have published their slides and such publicly [1]. However those is not super helpful for people who already understand assembly and computer architecture reasonably well. The best way I can see to get up to speed is to read some example demonstrating each instruction. I have thought about a site that has a table of instructions that links to an online simulator [2] to let you step through an example detailing edge cases. The best source of simple assembly examples I know of would be the tests from my project [3]. Though those could be a lot more helpful for a human reading them. As for simulators, there are quite a few. The website lists a bunch [4]. I am not sure how many would support any kind of machine mode memory mapping though. [0]: https://github.com/TheThirdOne/rars https://github.com/TheThirdOne/rars [1]: https://github.com/riscv/riscv-teach https://github.com/riscv/riscv-teach [2]: https://venus.cs61c.org/ https://venus.cs61c.org/ [3]: https://github.com/TheThirdOne/rars/tree/696ef9ed82285f0a73d80370c18be5524e95f0db/test https://github.com/TheThirdOne/rars/tree/696ef9ed82285f0a73d... [4]: https://riscv.org/software-status/ https://riscv.org/software-status/

ncmncm 7y ago

The riscv people missed some serious opportunities for fundamental improvements, probably the last such opportunity in this generation. Perhaps the biggest was that the comparison instruction should have had the condition being looked for in the instruction, and put the result in register 0 as a 0 or ~0 (= -1). Register renaming can then carry it through pipelines. Subsequent instructions may AND register 0 with other values, or subtract it from them, avoiding frequently mispredicted branches.

thethirdone 7y ago
I am not quite understanding the missed improvement you are talking about. Are you saying that instead of (or in addition to) "branch if equal", "branch if less than", etc there should be a "set if equal", "set if less than", etc? In case you are, there is a "set if less than" instruction. The floating point extension does have a "set if equal" instruction despite there not being an integer equivalent. Alternatively if you are complaining about 1 representing True rather than ~0, I don't think that matters much from a technical POV.
- ncmncm 7y ago
  The condition codes from comparison operations have always been a problem for out-of-order execution units. Feeding the result directly to the register bank sidesteps the problem. Conditional-move instructions have also been a problem, which this also sidesteps. Branch-register-zero and -nonzero instructions complete the set. The extra step to get a comparison result into a register, and another to extend it to the whole register, is an inefficiency I would prefer to leave behind.
  - jleahy 7y ago
    It's a single instruction to then subtract 1 from the result of SLT/SLTI, which then gives you 0xffffffff or 0x00000000 rather than 0 or 1, which you can use as a mask. RISC-V was designed to be a good target for a C compiler, given that's what people almost always need. Compilers frequently see code line `int x = (a > b)` and SLT is perfect for that. Compilers don't do clever masking tricks to avoid branches, in general (there are a few hard-coded tricks like divide by signed constant).
    - ncmncm 7y ago
      In other words, two more instructions, instead of zero. That compilers fail to do clever masking tricks to avoid branches frequently results in 2x slower programs.
      - avianes 7y ago
        No, as jleahy said, it cost a single instruction to transform 0 to 0b00..00 and 1 to 0b11..11 - SUB X, $0, X. And your proposal - using the zero register as a flag register - breaks way more micro-optimizations (like the simple ones described in "The RISC-V Reader" book) than it allows
    - bonzini 7y ago
      > Compilers don't do clever masking tricks to avoid branches, in general They actually do a lot of such tricks. Check out the GCC sources, for example tree-ssa-phiopt.c[1] and ifcvt.c[2] [1] https://github.com/gcc-mirror/gcc/blob/master/gcc/tree-ssa-phiopt.c https://github.com/gcc-mirror/gcc/blob/master/gcc/tree-ssa-p... [2] https://github.com/gcc-mirror/gcc/blob/master/gcc/ifcvt.c https://github.com/gcc-mirror/gcc/blob/master/gcc/ifcvt.c
rwmj 7y ago
RISC-V is meant to be a simple, unsurprising, boring architecture, with any clever stuff (such as macro op fusion) being done at the microarchitecture level. It's not a project for researching new architectures.
- beefhash 7y ago
  I really wish it was just one tiny less bit simple. The RISC-V spec doesn't specify that multiplication instructions (if implemented) need to be constant-time. Which means RISC-V cores will need stupid hacks for cryptography like these: https://bearssl.org/ctmul.html https://bearssl.org/ctmul.html
  - rwmj 7y ago
    It could be added in the future as a simple extension. (In fact I found at least two proposed crypto extensions with a simple search although neither mentions constant-time ops from a quick scan). There's a considerable penalty for all implementations if every multiply implementation has to be constant time.
    - ncmncm 7y ago
      That is another problem. The "optional extensions" have all the useful instructions in them, but typically just a couple of the instructions in each extension would provide most of its value. So, I don't get popcount because it's in the bitmanip extension along with 10M transistors' worth of clever stuff I don't need. Similarly, each of the other extension sets. It would be much more useful to define slices through all the defined ones, so you get either the absolute minimum core instructions, or add just the coremost of each extension set, or a more comfortable subset of each, or half of each, spiraling outward as transistor budget grows.
      - rwmj 7y ago
        10 million transistors is a tenth of a square millimeter on current nodes, but that aside you really wouldn't want such a complicated system of "sub-extensions" because it would be a nightmare to write software for. Either the software would only work for very specific sub-extension mixes, or would require layers of ifuncs to deal with all combinations of missing sub-extension features. The current system of fairly granular extensions, a useful base architecture, and profiles defining what extensions are guaranteed for particular application classes (eg "Unix server") is a nice compromise between extensibility and software/distro complexity.

Quequau 7y ago

This: > If you want to do any OS work, you need a system that implements the Privileged ISA. Supporting the Privileged ISA is synonymous to being able to run UNIX-like systems, because it brings user-/supervisor-mode distinction and paging. Working on real hardware is generally preferred to working in emulators, because the code eventually has to run on metal anyway and emulators can be too forgiving for certain classes of problems. There is a plethora of RISC-V microcontrollers for a couple of dollars that all don’t support the Privileged ISA. At the time of writing, the only board you can buy that does support it is the $1000 HiFive Unleased, which was beyond my “I just want to play around with this” budget. Suggests to me that it's at least part of why Stephen Marz [0] isn't trying to target a specific board with his project (which has been posted here a few times and I'm sorta following along). That pretty much kills most of the interest in RISC-V that I had in me. I guess I'll wait a few more years and check back again later. [0]: https://osblog.stephenmarz.com/index.html https://osblog.stephenmarz.com/index.html

pjc50 7y ago
For some reason, people have a fantasy that RISC-V is going to give them a sub-dollar microcontroller that runs Linux, rather than being like ARM where "microcontroller" and "Linux capable" and "server grade" are three entirely different market segments.
- rjsw 7y ago
  I have several ARM dev boards and am thinking of getting a PinePhone, am happy to pay upto $200 for something to play with but not $1000. The HiFive Unleashed is interesting in that it has a lot more RAM than cheap ARM dev boards, for the same money though I could get a HoneyComb LX2K ARM system.
  - floatboth 7y ago
    Not for the same money, for much cheaper. HiFive Unleashed is $1000 for the board with onboard RAM… but it does not have PCIe onboard, so if you want that, you could pay $2000 extra (!!) for the "HiFive Unleashed Expansion Board" that has a giant FPGA that has a PCIe root complex programmed on it. HoneyComb LX2K is $750 for the board with 64GB eMMC + bring your own SODIMMs for RAM. SolidRun also offers the MACCHIATObin for $339. 4-core A72 + 4GB full-size DIMM included. (The single-channel-ness of the RAM is not good for performance, but you can install a big 16GB DIMM no problem.) Both the LX2K and the mcbin have PCIe of course :)

Annatar 7y ago

"While reading the rest of this post, please keep in mind: RISC-V is simple!" That's either a lie, or the author is severely traumatized from coding on x86 and is suffering from the Stockholm syndrome. Poor author; I feel sorry for the bloke. Code on UltraSPARC or MC68000 family of processors and then you will know what simple means. The instruction set of RISC-V is insane, absolutely insane.

legulere 7y ago
As I am someone who has never seen assembly from those languages, can you explain to me what is insane about RISC-V?
- Annatar 7y ago
  By definition, RISC stands for "reduced instruction set computer". And RISC-V exposes its internals so it has way more instructions than a conventional CISC processor, a lot of which deal with its internal states. Here is a good example[1]: For general signed addition, three additional instructions after the addition are required, leveraging the observation that the sum should be less than one of the operands if and only if the other operand is negative. add t0, t1, t2 slti t3, t2, 0 slt t4, t0, t1 bne t3, t4, overflow ...good luck programming this insane design with anything other than a high level language compiler. [1] https://riscv.org/specifications/ https://riscv.org/specifications/
  - avianes 7y ago
    > And RISC-V exposes its internals But your example shows no internal states exposure, it's just arithmetic to detect overflow. What are you trying to show ?
  - Symmetry 7y ago
    Generally, the "reduced instruction set" in RISC refers to how many instructions are available to the programmer, i.e. not many, rather than the larger number of instructions it then takes to accomplish anything. And the difficulty isn't really about exposing the internals, this isn't like a branch delay slot for instance. It's about making the relationship between instructions conceptually simple where there's always up to 2 inputs and up to one output. That doesn't help much in cases where the processor is doing something close to what the instructions are saying but it makes the simplest possible out of order processor, where the internals diverge wildly from the ISA, much easier to create. EDIT: Also, the using C and compiling rather than doing assembly by hand is really a fundamental part of the whole RISC philosophy and RISC-V is just a more extreme form of that.

gumby 7y ago

TBF Intel's x86 documentation has evolved incrementally over the last 40+ years. And it comes from an older tradition of engineering documentation which seems to have fallen by the wayside over the last 20 years or so. At an extreme, some ARM vendors like Mediatek don't even produce data sheets, as their model is one of chip+consulting.

jhallenworld 7y ago

I just tried the Project Trellis open source FPGA tool chain for RISC-V. I was forced into it: a few years ago I bought the Lattice ECP5-5G Versa Dev kit (on sale at the time for $99, $200 now I think). The Lattice tools for the FPGA on this board requires a license. Well the license ran out, and I don't want to pay $900 for a Diamond license. Anyway, I got this example from Project Trellis to work on this board. It uses this "PICO RISC-V" (the entire CPU is in a single Verilog file): https://github.com/SymbiFlow/prjtrellis/tree/master/examples/picorv32_versa5g https://github.com/SymbiFlow/prjtrellis/tree/master/examples... I think it would be straightforward to build a Linux capable RISC-V system for this board using this free tool chain. The board has SDRAM, FTDI UART and SPI-flash. It does not have an SD slot, but maybe could be wired in with the expansion headers. This ULX3S board also looks promissing, but is not available yet: https://www.crowdsupply.com/radiona/ulx3s https://www.crowdsupply.com/radiona/ulx3s What's very cool is that low end ECP5 FPGAs are around $5. I think RISC-V on an ECP5 with LCD touch interface might be the cheapest available option for a Linux microcontroller with a touch LCD interface. By available, I mean where you can easily buy the chips on mainstream distributors (otherwise it would for sure be some AllWinner chip).

kersny 7y ago
A RISC-V linux system for the ECP5 can be built with the FOSS toolchain using vexriscv and litex: https://github.com/litex-hub/linux-on-litex-vexriscv https://github.com/litex-hub/linux-on-litex-vexriscv also, step by step using a different core (rocket): https://insights.sei.cmu.edu/sei_blog/2019/10/how-to-build-a-trustworthy-freelibre-linux-capable-64-bit-risc-v-computer.html https://insights.sei.cmu.edu/sei_blog/2019/10/how-to-build-a...
- jhallenworld 7y ago
  I'm amazed to see the preferred toolchain for LiteX for ECP5 listed as "Yosys/Trellis/Nextpnr" (and vendor proprietary tools for the other families). The rocket core mentions 102% of space used of an 85K LUT FPGA and having to deal with it. I wonder which core is using so much space? I have more experience with vendor soft cores, and they would use much less..