5 ms·

RISC-V Public review for standard extensions Zc

94 points by snvzz 4y ago

snvzz 4y ago
Comments here: https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/j2xJAKSSMDo https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/j2x...
throwaway81523 4y ago
RISC-V gets more and more complicated all the time. N different extensions of which almost any subset is a valid combo, so 2**N variants. Meanwhile, nothing about fast integer overflow detection.
- Jtsummers 4y ago
  2^N (I'm guessing you typed two *s, you need to type 4 to get two to show up). ** => * **** => **
  - throwaway81523 4y ago
    Thanks, fixed.
- wyldfire 4y ago
  I think the RISC-V committees/foundation realized the problem and is endorsing specific combinations of extensions.
  - snvzz 4y ago
    Rather than "realized the problem", it would be more accurate to say that they understood the ramifications of extensions from the very beginning, took adequate steps, and never allowed it to become a problem.
- brucehoult 4y ago
  It's not a problem because: - if you're compiling your own software you just tell the compiler what extensions the hardware you're using has. - if you're running shrink-wrapped software today then you currently know exactly that RV64GC is supported, and next year you'll know there are 2.5 possibilities: RVA20 (RV64GC renamed), and RVA22 with or without V extension. I expect the next one (RVA24 or RVA25 or something) will make V compulsory. If you actually genuinely care about fast integer overflow detection on RISC-V then make a proposal, analysing the costs and benefits. As far as most people are concerned, there isn't a problem there in the first place.
  - throwaway81523 4y ago
    > As far as most people are concerned, there isn't a problem there [fast overflow detection] in the first place. See, that is the problem. They try to be an architecture for the future but they are only concerned about performance of legacy code that doesn't check overflow either. The result is a zillion CVE's from overflow bugs, to go with the buffer overflows. Idk whether Rust is supposed to check overflow. Ada is supposed to check unless you suppress the check with a pragma, but GNAT sets the pragma by default because doing the check costs too much performance even on x86. The Ada designers were not being fools when they specified that these checks should be done all the time. So an architecture of the future should support doing that efficiently, just like the CHERI(?) extension supports checking pointers efficiently. As for the many combinations of features: it will be like x86 I guess, where it is a hassle but ultimately not a crushing one. Usually people just give up some performance by using lowest common denominator (or should that be greatest common factor) executables.
    - brucehoult 4y ago
      Not having dedicated overflow checking instructions doesn't mean that you can't check overflows. You can. There is no problem because checking overflows doesn't in practice cause significant overhead, especially in the kinds of superscalar CPUs that are in mobile devices and laptops and PCs and servers these days. Most of the time those wide OoO CPUs are looking in vain for more parallelism. Adding a few overflow-checking instructions just gives them something to do with execution slots they otherwise often can't use. If there is a actual problem -- which needs to be PROVEN not just hand-waved -- then analyse it in the real world, document it, propose an ISA extension that would actually make things better in real-world applications, not just some hand-picked tiny loop or function.
- rwmj 4y ago
  Have you tried this recently? grep ^flags /proc/cpuinfo
- dzaima 4y ago
  Mentioning 2^N variants on this specific proposal is probably the worst place to do so - Zca, Zcf, Zcd are all subsets of the 'c' extension, and Zcmp is incompatible with the 'c' extension, which severely cuts down the combinations - having the 'c' extension, which Linux expects, makes all (but Zcb I think?) extensions here either implicitly supported, or incompatible. And, given the scope & purpose of these extensions, most things (distributed binary programs, OSes, all but a few compilers) won't need to use nor care about these. The alternative to these extensions, to those that need them, would be either suffering decreased performance/increased ROM size, choosing a different architecture, or making proprietary extensions (at which point you could have multiple vendors with incompatible extensions doing the same thing) - all of which are bad alternatives.
brucehoult 4y ago
Note that these extensions are primarily aimed at tiny embedded systems with code in ROM and no caches, so instruction fetch competing with data load/store is an issue. That was the major justification for load/store multiple in the 1985 ARM ISA, but it's been dropped or deprecated in recent ARM -A ISAs. Byte and half load/store are also a lot more common in embedded software than in applications processors (especially as they are often handled by SIMD/Vector in larger CPUs) Note that the B extension already added instructions such as manipulating single bits in registers (Zbs); clz, cpop, byte reverse, rotates (Zbb); and shift-and-add (Zba) The Zcmp and Zcmt extensions are NOT intended to be added to large applications processors running standard OSes such as Linux or Android. This is about competing with 8051, AVR, PIC, MSP430, ARMv6-M, ARMv7-M at the lowest end.
- wyldfire 4y ago
  > 1985 ARM ISA, but it's been dropped or deprecated in recent ARM -A ISAs I guess the idea is to recover the opcode space? Or recover the area used to implement it? Seems like deprecating instructions for an ISA doesn't really have any effect other than giving you more notice for the eventual removal. Unless you sit down and read the new PRM you'd probably never know.
  - phire 4y ago
    ARMv8-A (aka 64bit ARM) is a completely different instruction set, with basically zero relation to the instruction encoding of 32bit ARM. They redesigned it from scratch. And it's an instruction set designed for high-performance application cores (hence the -A) like what you would find as the main processor of a mobile phone, or a laptop or even a server. So they don't want anything optimised for lower-end designs. Plenty of other useful things to do with the encoding space. For those low-end designs, ARM have a second ISA called ARMv8-M. Which is basically just the old thumb mode of 32bit arm with a few improvements. The original 32bit arm ISA is basically dead these days (at least for new designs). You can still run some ARMv8-A chips in 32bit ARM mode, for compatibility. But that's actually optional in regards to the spec. Some only support running usermode 32bit ARM code. In the near future, we will see some cores that don't support 32bit arm code at all.
keepquestioning 4y ago
sylware 4y ago
It seems risc-v is missing the "small and big", "hardware accelerated", equilavent of x86 "rep stosX" and "rep movsX". Basically hardware memcpys and memsets. Heard latest arm ISA has them. risc-v implementors/experts out there: is this true?
- childintime 4y ago
  not an expert, but it seems to me the vector extension should be able to do this.
  - sylware 4y ago
    Like on ARM with neon and x86 with avx, but even on those, they got direct hardware acceleration without neon/avx of memcpys and memsets (big and small).

94 points by snvzz 4y ago

Comments here: https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/j2xJAKSSMDo https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/j2x...

throwaway81523 4y ago

RISC-V gets more and more complicated all the time. N different extensions of which almost any subset is a valid combo, so 2**N variants. Meanwhile, nothing about fast integer overflow detection.

Jtsummers 4y ago
2^N (I'm guessing you typed two *s, you need to type 4 to get two to show up). ** => * **** => **
- throwaway81523 4y ago
  Thanks, fixed.
wyldfire 4y ago
I think the RISC-V committees/foundation realized the problem and is endorsing specific combinations of extensions.
- snvzz 4y ago
  Rather than "realized the problem", it would be more accurate to say that they understood the ramifications of extensions from the very beginning, took adequate steps, and never allowed it to become a problem.
brucehoult 4y ago
It's not a problem because: - if you're compiling your own software you just tell the compiler what extensions the hardware you're using has. - if you're running shrink-wrapped software today then you currently know exactly that RV64GC is supported, and next year you'll know there are 2.5 possibilities: RVA20 (RV64GC renamed), and RVA22 with or without V extension. I expect the next one (RVA24 or RVA25 or something) will make V compulsory. If you actually genuinely care about fast integer overflow detection on RISC-V then make a proposal, analysing the costs and benefits. As far as most people are concerned, there isn't a problem there in the first place.
- throwaway81523 4y ago
  > As far as most people are concerned, there isn't a problem there [fast overflow detection] in the first place. See, that is the problem. They try to be an architecture for the future but they are only concerned about performance of legacy code that doesn't check overflow either. The result is a zillion CVE's from overflow bugs, to go with the buffer overflows. Idk whether Rust is supposed to check overflow. Ada is supposed to check unless you suppress the check with a pragma, but GNAT sets the pragma by default because doing the check costs too much performance even on x86. The Ada designers were not being fools when they specified that these checks should be done all the time. So an architecture of the future should support doing that efficiently, just like the CHERI(?) extension supports checking pointers efficiently. As for the many combinations of features: it will be like x86 I guess, where it is a hassle but ultimately not a crushing one. Usually people just give up some performance by using lowest common denominator (or should that be greatest common factor) executables.
  - brucehoult 4y ago
    Not having dedicated overflow checking instructions doesn't mean that you can't check overflows. You can. There is no problem because checking overflows doesn't in practice cause significant overhead, especially in the kinds of superscalar CPUs that are in mobile devices and laptops and PCs and servers these days. Most of the time those wide OoO CPUs are looking in vain for more parallelism. Adding a few overflow-checking instructions just gives them something to do with execution slots they otherwise often can't use. If there is a actual problem -- which needs to be PROVEN not just hand-waved -- then analyse it in the real world, document it, propose an ISA extension that would actually make things better in real-world applications, not just some hand-picked tiny loop or function.
rwmj 4y ago
Have you tried this recently? grep ^flags /proc/cpuinfo
dzaima 4y ago
Mentioning 2^N variants on this specific proposal is probably the worst place to do so - Zca, Zcf, Zcd are all subsets of the 'c' extension, and Zcmp is incompatible with the 'c' extension, which severely cuts down the combinations - having the 'c' extension, which Linux expects, makes all (but Zcb I think?) extensions here either implicitly supported, or incompatible. And, given the scope & purpose of these extensions, most things (distributed binary programs, OSes, all but a few compilers) won't need to use nor care about these. The alternative to these extensions, to those that need them, would be either suffering decreased performance/increased ROM size, choosing a different architecture, or making proprietary extensions (at which point you could have multiple vendors with incompatible extensions doing the same thing) - all of which are bad alternatives.

brucehoult 4y ago

Note that these extensions are primarily aimed at tiny embedded systems with code in ROM and no caches, so instruction fetch competing with data load/store is an issue. That was the major justification for load/store multiple in the 1985 ARM ISA, but it's been dropped or deprecated in recent ARM -A ISAs. Byte and half load/store are also a lot more common in embedded software than in applications processors (especially as they are often handled by SIMD/Vector in larger CPUs) Note that the B extension already added instructions such as manipulating single bits in registers (Zbs); clz, cpop, byte reverse, rotates (Zbb); and shift-and-add (Zba) The Zcmp and Zcmt extensions are NOT intended to be added to large applications processors running standard OSes such as Linux or Android. This is about competing with 8051, AVR, PIC, MSP430, ARMv6-M, ARMv7-M at the lowest end.

wyldfire 4y ago
> 1985 ARM ISA, but it's been dropped or deprecated in recent ARM -A ISAs I guess the idea is to recover the opcode space? Or recover the area used to implement it? Seems like deprecating instructions for an ISA doesn't really have any effect other than giving you more notice for the eventual removal. Unless you sit down and read the new PRM you'd probably never know.
- phire 4y ago
  ARMv8-A (aka 64bit ARM) is a completely different instruction set, with basically zero relation to the instruction encoding of 32bit ARM. They redesigned it from scratch. And it's an instruction set designed for high-performance application cores (hence the -A) like what you would find as the main processor of a mobile phone, or a laptop or even a server. So they don't want anything optimised for lower-end designs. Plenty of other useful things to do with the encoding space. For those low-end designs, ARM have a second ISA called ARMv8-M. Which is basically just the old thumb mode of 32bit arm with a few improvements. The original 32bit arm ISA is basically dead these days (at least for new designs). You can still run some ARMv8-A chips in 32bit ARM mode, for compatibility. But that's actually optional in regards to the spec. Some only support running usermode 32bit ARM code. In the near future, we will see some cores that don't support 32bit arm code at all.

keepquestioning 4y ago

sylware 4y ago

It seems risc-v is missing the "small and big", "hardware accelerated", equilavent of x86 "rep stosX" and "rep movsX". Basically hardware memcpys and memsets. Heard latest arm ISA has them. risc-v implementors/experts out there: is this true?

childintime 4y ago
not an expert, but it seems to me the vector extension should be able to do this.
- sylware 4y ago
  Like on ARM with neon and x86 with avx, but even on those, they got direct hardware acceleration without neon/avx of memcpys and memsets (big and small).