7 ms·

> RISC-V isn't an architecture you'd want to run a computer on. Why not, too risky? Joking aside can anyone explain why this is the case? Is it the classical r

> RISC-V isn't an architecture you'd want to run a computer on. Why not, too risky? Joking aside can anyone explain why this is the case? Is it the classical risc vs cisc debate?

deleted 5y ago
[deleted]
ahartmetz 5y ago
There was an article on HN where someone called RISC-V a bit too RISCy. ARM has instructions that combine things that are commonly combined, which increases code density and requires fewer instruction decoders (as well as possibly instruction combine logic if there are micro/macro-ops) for the same performance.
- phkahler 5y ago
  RISC-V had better code density than anything a few years back. Cant say how it competes with the latest though. It does have some weird instruction encodings though. They intended it to be fixed 32bit instructions, but then that changed and its let with some odd things because of it. I'd like to see immediate data come after the instruction.
  - brucehoult 5y ago
    In 32 bit, Thumb2 aka ARMv7 has slightly better code density than RISC-V. In 64 bit, RISC-V has by far the most dense code compared to ARM, x86, POWER or any other widely used 64 bit ISA. ARM dropped their 2-byte encodings going from 32 to 64 bit, which hurts them a lot. i386/i686 was reasonably dense, but amd64 needs a lot of REX prefix bytes which increases the code size. RISC-V was always designed to allow for variable instruction lengths. The base instruction set is fixed-length 32 bit -- 30 bit really, as the two LSBs are always '11'. Values of the two LSBs other than '11' were always intended for 16 bit instructions. Encodings with all 1s in the "major opcode" field are reserved to indicate future instructions longer than 32 bits. It's very likely that the first such instructions defined will be 48 bit instructions with 32 bit immediate data. However until now, RISC-V core designers have been strongly resisting adding instructions longer than 32 bits even though software people want them. It might look cleaner to load a 32 bit literal using a single 48 bit instruction instead of two 32 bit instructions, but it might not make for a faster computer.
- ch_123 5y ago
  That is an implementation detail of the processor hardware, and not of the instruction set, unless you have some details on why RISC-V cannot be implemented this way.
  - ahartmetz 5y ago
    It is absolutely a property of the instruction set. In the meantime, I remembered two prominent examples: ARM has compare-and-branch instructions and load / store with offset and scaling instructions. There is no way to get the benefits of less decoding and possibly combining (possibly also reduced register pressure and shorter dependency chains - no intermediate address calculations or comparison status registers) without changing the instruction set.
    - zozbot234 5y ago
      RISC-V has compare-and-branch instructions, and load/store instructions w/ an offset field. Scaling can be achieved via insn fusion.
      - ahartmetz 5y ago
        Thanks for the correction. RISC-V actually seems to have the most efficient way to do conditional branches of all common ISAs (according to its instruction set reference document, heh). But about the more complex ARM load/store opcodes, the point stands that instruction fusion does not simplify decoding or increase code density the way a pre-fused instruction does.
        brucehoult 5y ago
        "pre-fused" instructions use up a lot of opcode space that might be better used for other things. Complex addressing modes help code size if you've got just a single access to an array element in some straight line code, but they're seldom needed in loops because most of the calculation is best moved outside of the loop leaving just a simple pointer increment inside the loop.
    - deleted 5y ago
- saagarjha 5y ago
  https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d9982f7618ef68 https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d99...
mojuba 5y ago
Not knowledgeable in the area, but from what I gather RISC-V is not as performant as ARM or Intel/AMD. Yes it can run at faster clock speeds due to its simplicity, but the flip side is that it requires more instructions (and more memory and more cache) to do the same job. Besides, there don't seem to be good multicore architectures for RISC-V, that's probably the biggest show stopper in this age of multicore computing.
- Someone 5y ago
  I don’t think lack of good multicore designs would be a showstopper for Apple. They have a team that could change that, and can afford to spend a few billions on doing it.
- zozbot234 5y ago
  > but the flip side is that it requires more instructions (and more memory and more cache) to do the same job. The opposite is true. RISC-V has a compressed-instructions extension that makes its code density competitive with x86, ARM64 has nothing like that. Add the earlier-mentioned improvements due to it being a clean, from-scratch redesign and a 20% improvement in performance per watt given similar process node and microarchitecture is very much in the ballpark.
  - lucian1900 5y ago
    The compressed instructions are not fixed length, so decoding in parallel is severely restricted. No high performance RISC-V machine would use that extension.
    - trasz 5y ago
      They are not fixed length (usual instructions are 4 bytes, compressed are 2), but iirc you can easily tell the length using a single bit in the opcode, so it shouldn’t be that bad. It’s much closer to fixed-length than real variable-length, like with x86.
      - 5y ago
Taniwha 5y ago
No, it's simply that RISC-V is relatively new, we've seen a bunch of small slower cores come out first, they're easier and quicker to design, the bigger faster ones are coming they just take more time to design
- zozbot234 5y ago
  Bigger and faster cores are also expected to include extensions that are yet to be standardized, so waiting is absolutely the right move. There are draft architectures (including multiple versions of the openly-available Berkeley Out of Order Machine "BOOM") that are expected to have quite compelling results once fabbed.
  - brucehoult 5y ago
    The most important of those extensions will all be ratified as part of the RVA22 profile before the end of the year -- including Vector, Bitmanip, Cache control, Scalar crypto, and I think possibly pointer masking (a big big security thing). A number of companies will already have chips designed and ready to go using draft versions of those extensions. Any minor changes during the public review period will be able to be incorporated very quickly, with chips taping out possibly before New Year. The time to hire programmers to write the software is well before you have chips sitting in the warehouse (or sold in products), not after.
- brucehoult 5y ago
  I don't know if you noticed, but ARM also only makes relatively small and slow cores. Apple made something called the "M1" which uses ARM's instruction set but isn't small and slow. If Apple turned the M1 team to making a RISC-V core, it would perform just as well.
barkingcat 5y ago
I think it is too risky at the moment, but in the future anything could happen. RISC-V still has a lot of undefined portions, and because of the way the architectural design is run in the open, it has a committee that is supposed to meet to evaluate proposals about fundamental parts of the architecture, things like memory management, what kind of arithmetic units and floating point units, what kind of instructions are in the instruction sets etc. If you look at the spec there are a lot of basic instructions that are "stubs" - basically they have the instruction names, but no implementation yet - and this is for quite basic parts of the instruction set. Individual RISC-V vendors/manufacturers are "designing their own" and trying to flesh it out, but in many cases they are not standard and may very well be proprietary. I see this job posting as Apple recognizing that it is early in the game and that they'd really like to "set the direction" of RISC-V in a way that helps them (which only makes sense) RISC-V is a long game - probably will yield rewards in about 10 years. But no. You would not want a PC built on RISC-V now (and the question now is "which" RISC-V, the one with memory management or the one without?) - even for embedded boards, for example Beagle Board recently cancelled their BeagleV board https://beaglev.org/blog/2021-07-30-the-future-of-beaglev-community https://beaglev.org/blog/2021-07-30-the-future-of-beaglev-co... not saying that Beagle is leaving Risc-v but most likely they want to use a different instruction set flavour of Risc-v and the current landscape is just too unstable (ie different hardware manufacturers have "different" Risc-v's and software won't run on one kind vs another kind)
- zozbot234 5y ago
  > If you look at the spec there are a lot of basic instructions that are "stubs" - basically they have the instruction names, but no implementation yet The "stub" parts of the spec are for yet-to-be-ratified extensions, there's a number of those in the pipeline including 'V' for vector compute and 'B' for bit manipulation. Those are indeed quite useful for general purpose compute, but one can hope that they'll take far less than 10 years to ratify.
  - brucehoult 5y ago
    Before the end of the year. "B" is already well into the 45 day Public Comment stage which is the last step before ratification. "V" is expected to enter that shortly. The "Scalar Crypto" extension entered the Public Comment stage a few days ago.

> RISC-V isn't an architecture you'd want to run a computer on. Why not, too risky? Joking aside can anyone explain why this is the case? Is it the classical risc vs cisc debate?

deleted 5y ago

[deleted]

ahartmetz 5y ago

There was an article on HN where someone called RISC-V a bit too RISCy. ARM has instructions that combine things that are commonly combined, which increases code density and requires fewer instruction decoders (as well as possibly instruction combine logic if there are micro/macro-ops) for the same performance.

phkahler 5y ago
RISC-V had better code density than anything a few years back. Cant say how it competes with the latest though. It does have some weird instruction encodings though. They intended it to be fixed 32bit instructions, but then that changed and its let with some odd things because of it. I'd like to see immediate data come after the instruction.
- brucehoult 5y ago
  In 32 bit, Thumb2 aka ARMv7 has slightly better code density than RISC-V. In 64 bit, RISC-V has by far the most dense code compared to ARM, x86, POWER or any other widely used 64 bit ISA. ARM dropped their 2-byte encodings going from 32 to 64 bit, which hurts them a lot. i386/i686 was reasonably dense, but amd64 needs a lot of REX prefix bytes which increases the code size. RISC-V was always designed to allow for variable instruction lengths. The base instruction set is fixed-length 32 bit -- 30 bit really, as the two LSBs are always '11'. Values of the two LSBs other than '11' were always intended for 16 bit instructions. Encodings with all 1s in the "major opcode" field are reserved to indicate future instructions longer than 32 bits. It's very likely that the first such instructions defined will be 48 bit instructions with 32 bit immediate data. However until now, RISC-V core designers have been strongly resisting adding instructions longer than 32 bits even though software people want them. It might look cleaner to load a 32 bit literal using a single 48 bit instruction instead of two 32 bit instructions, but it might not make for a faster computer.
ch_123 5y ago
That is an implementation detail of the processor hardware, and not of the instruction set, unless you have some details on why RISC-V cannot be implemented this way.
- ahartmetz 5y ago
  It is absolutely a property of the instruction set. In the meantime, I remembered two prominent examples: ARM has compare-and-branch instructions and load / store with offset and scaling instructions. There is no way to get the benefits of less decoding and possibly combining (possibly also reduced register pressure and shorter dependency chains - no intermediate address calculations or comparison status registers) without changing the instruction set.
  - zozbot234 5y ago
    RISC-V has compare-and-branch instructions, and load/store instructions w/ an offset field. Scaling can be achieved via insn fusion.
    - ahartmetz 5y ago
      Thanks for the correction. RISC-V actually seems to have the most efficient way to do conditional branches of all common ISAs (according to its instruction set reference document, heh). But about the more complex ARM load/store opcodes, the point stands that instruction fusion does not simplify decoding or increase code density the way a pre-fused instruction does.
      - brucehoult 5y ago
        "pre-fused" instructions use up a lot of opcode space that might be better used for other things. Complex addressing modes help code size if you've got just a single access to an array element in some straight line code, but they're seldom needed in loops because most of the calculation is best moved outside of the loop leaving just a simple pointer increment inside the loop.
  - deleted 5y ago
saagarjha 5y ago
https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d9982f7618ef68 https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d99...

mojuba 5y ago

Not knowledgeable in the area, but from what I gather RISC-V is not as performant as ARM or Intel/AMD. Yes it can run at faster clock speeds due to its simplicity, but the flip side is that it requires more instructions (and more memory and more cache) to do the same job. Besides, there don't seem to be good multicore architectures for RISC-V, that's probably the biggest show stopper in this age of multicore computing.

Someone 5y ago
I don’t think lack of good multicore designs would be a showstopper for Apple. They have a team that could change that, and can afford to spend a few billions on doing it.
zozbot234 5y ago
> but the flip side is that it requires more instructions (and more memory and more cache) to do the same job. The opposite is true. RISC-V has a compressed-instructions extension that makes its code density competitive with x86, ARM64 has nothing like that. Add the earlier-mentioned improvements due to it being a clean, from-scratch redesign and a 20% improvement in performance per watt given similar process node and microarchitecture is very much in the ballpark.
- lucian1900 5y ago
  The compressed instructions are not fixed length, so decoding in parallel is severely restricted. No high performance RISC-V machine would use that extension.
  - trasz 5y ago
    They are not fixed length (usual instructions are 4 bytes, compressed are 2), but iirc you can easily tell the length using a single bit in the opcode, so it shouldn’t be that bad. It’s much closer to fixed-length than real variable-length, like with x86.
    - 5y ago

Taniwha 5y ago

No, it's simply that RISC-V is relatively new, we've seen a bunch of small slower cores come out first, they're easier and quicker to design, the bigger faster ones are coming they just take more time to design

zozbot234 5y ago
Bigger and faster cores are also expected to include extensions that are yet to be standardized, so waiting is absolutely the right move. There are draft architectures (including multiple versions of the openly-available Berkeley Out of Order Machine "BOOM") that are expected to have quite compelling results once fabbed.
- brucehoult 5y ago
  The most important of those extensions will all be ratified as part of the RVA22 profile before the end of the year -- including Vector, Bitmanip, Cache control, Scalar crypto, and I think possibly pointer masking (a big big security thing). A number of companies will already have chips designed and ready to go using draft versions of those extensions. Any minor changes during the public review period will be able to be incorporated very quickly, with chips taping out possibly before New Year. The time to hire programmers to write the software is well before you have chips sitting in the warehouse (or sold in products), not after.
brucehoult 5y ago
I don't know if you noticed, but ARM also only makes relatively small and slow cores. Apple made something called the "M1" which uses ARM's instruction set but isn't small and slow. If Apple turned the M1 team to making a RISC-V core, it would perform just as well.

barkingcat 5y ago

I think it is too risky at the moment, but in the future anything could happen. RISC-V still has a lot of undefined portions, and because of the way the architectural design is run in the open, it has a committee that is supposed to meet to evaluate proposals about fundamental parts of the architecture, things like memory management, what kind of arithmetic units and floating point units, what kind of instructions are in the instruction sets etc. If you look at the spec there are a lot of basic instructions that are "stubs" - basically they have the instruction names, but no implementation yet - and this is for quite basic parts of the instruction set. Individual RISC-V vendors/manufacturers are "designing their own" and trying to flesh it out, but in many cases they are not standard and may very well be proprietary. I see this job posting as Apple recognizing that it is early in the game and that they'd really like to "set the direction" of RISC-V in a way that helps them (which only makes sense) RISC-V is a long game - probably will yield rewards in about 10 years. But no. You would not want a PC built on RISC-V now (and the question now is "which" RISC-V, the one with memory management or the one without?) - even for embedded boards, for example Beagle Board recently cancelled their BeagleV board https://beaglev.org/blog/2021-07-30-the-future-of-beaglev-community https://beaglev.org/blog/2021-07-30-the-future-of-beaglev-co... not saying that Beagle is leaving Risc-v but most likely they want to use a different instruction set flavour of Risc-v and the current landscape is just too unstable (ie different hardware manufacturers have "different" Risc-v's and software won't run on one kind vs another kind)

zozbot234 5y ago
> If you look at the spec there are a lot of basic instructions that are "stubs" - basically they have the instruction names, but no implementation yet The "stub" parts of the spec are for yet-to-be-ratified extensions, there's a number of those in the pipeline including 'V' for vector compute and 'B' for bit manipulation. Those are indeed quite useful for general purpose compute, but one can hope that they'll take far less than 10 years to ratify.
- brucehoult 5y ago
  Before the end of the year. "B" is already well into the 45 day Public Comment stage which is the last step before ratification. "V" is expected to enter that shortly. The "Scalar Crypto" extension entered the Public Comment stage a few days ago.