6 ms·

I have some mixed feelings about most of these. As Jim Keller said, "most of the performance comes from just six instruction and RISC-V has all of those". Add

I have some mixed feelings about most of these. As Jim Keller said, "most of the performance comes from just six instruction and RISC-V has all of those". Adding more instructions will cost area, power, design & verification time, all of which could go to making the existing code go faster.

YorkshireSeason 5y ago
The beauty of a modular instruction set architecture like RISCV's is that you don't have to implement all of it, only the extensions that make sense for your use case. Aside, Keller's quote is probably partly in jest. If you are in a constrained micro-controller environment something like the ZFinx extension is probably helpful beyond the "just six instructions" for code density. If you are crypto heavy, the crypto extension are going to be more helpful than "just six instructions". If your workload is parallelisable and regular, vectorisation helps you more than "just six instructions" and so on. One size doesn't fit all.
- bee_rider 5y ago
  How does the modular instruction set work? If someone proposes an extension, is the onus on them to also provide a minimal RISCV implementation of that functionality? Or is it just accepted that some binaries won't work on all devices?
  - forty 5y ago
    I have no idea for Riscv specifically, but x86/amd64 have a lot of optional instructions (I'm mostly aware of vector stuff like SSE, AVX but I'm sure there are other stuff). On the programming side, you can detect at runtime feature support and use specific code path accordingly, or decide at compile time that you require a specific CPU feature and then your binary will just not work on CPUs without the feature.
  - Pet_Ant 5y ago
    > Or is it just accepted that some binaries won't work on all devices? Yes. Just like you cannot run Pentium code on a 386 because they added new extensions. Or how Scheme isn't really a programming language but more like a _family_ of very nearly compatible languagues. RISCV has multiple targets and so so they have very different needs from embedded automotive to desktop. But with a common core is easier to develop and share tooling.
  - deleted 5y ago
    [deleted]
  - YorkshireSeason 5y ago
    It's best to think of RISCV not as a single ISA (= instruction set architecture), but a parametric ISA. The extensions are parameters. RISCV offers lots of official extensions to choose from, such as M, A, F, D, P, V, .... In addition you have the 32 vs 64 bit data width parameter. Any specific ISA will have to instantiate those parameters, like e.g. so: RISCV32MFP or RISCV64MAF. Any implementation of e.g. RISCV64MAF will have to implement in silicon exactly those assembly command (and supporting features) that the M, A and F extension demand, with 64 bit register width. Like in OO-programming the class constructors take arguments that parameterise the created object. ------ Regarding an implementation, given that RISCV is an ISA, not an ISA implementation, you need to provide a functional model. The official standard is [1] but it's a bit behind the ratified extensions. For example [2] defines the (ISA-visible) registers, while [3] gives you the instruction decoding and execution clause for the most base instruction set. [4] describes part of one of the available address translation modes (for the 32 bit variant of the ISA). Note: in modern processors page-table walks are hardware accelerated, so OS and processor need to use the same format here, which is why this is part of the ISA. [1] https://github.com/riscv/sail-riscv/tree/master/model https://github.com/riscv/sail-riscv/tree/master/model [2] https://github.com/riscv/sail-riscv/blob/master/model/riscv_regs.sail https://github.com/riscv/sail-riscv/blob/master/model/riscv_... [3] https://github.com/riscv/sail-riscv/blob/master/model/riscv_insts_base.sail https://github.com/riscv/sail-riscv/blob/master/model/riscv_... [4] https://github.com/riscv/sail-riscv/blob/master/model/riscv_vmem_sv32.sail https://github.com/riscv/sail-riscv/blob/master/model/riscv_...
  - panick21_ 5y ago
    The way it works is that there are profiles. The idea behind profiles is that different use cases define profiles with the instruction extensions the require or are optional and so on. So the major Linux distros agree on a set of instructions and that's called a profile. Same for embedded and others eventually. You can add your own extensions for yourself if you want. You can also make extentions and try to make it a sudo standard. Or you can attempt to make it into a standard extention. To be a standard extension it has to go threw a long process and it will likely be tapped out multiple times before it is ever ratified. Once its ratified it will find its way into profiles. So for example standard Linux distros now use RV64GC, likely the next version of the Linux profile will include more of the new instructions. But yes, the goal is not to create a 'universal binary'. But a reasonable compromise between reuse and specialization.
- bsder 5y ago
  > One size doesn't fit all. True, but a standard that is too malleable isn't really a standard at all.
  - snvzz 5y ago
    If you're building a chip for a server, workstation, laptop, smartphone, then you'll want to adhere to a platform spec profile. RVA22[0] is the first such profile, and among other important things which go a long way to ease cross-vendor software compatibility, it does require RVA22U and RVA22S, which in turn require a set of extensions. [0]: https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc https://github.com/riscv/riscv-platform-specs/blob/main/risc...
  - neilalexander 5y ago
    In probably any “open” ISA, vendors/manufacturers are likely to “fork it” and show up with their own extensions anyway. By embracing extensions as a first-class concept, it would seem RISC-V is trying to embrace variance rather than to repeat the mistakes of architectures like amd64 (which has multiple “microarchitecture levels” and only the lowest level is truly portable).
    - panick21_ 5y ago
      To a certain extent yes they embrace variance but to a certain extent they don't. The idea is that what is dominates is software. If you add your own extensions, literally all software in the world wont support it. You will need to provide a huge amount of stuff to fully take advantage of that. The availability of software both open and commercial on top of standardized profiles targets should be what manufacturers target. Early on of course, manufactures have provided things that are not standard yet. However over time, does it really make sense to supply your own bit manipulation extension? As the standard grows the waste majority of application should not require or be really improved by proprietary extensions. Of course if somebody comes along and makes a chip that is just vastly better then what anybody else has with some extensions. That could break that paradigm and people might embrace it.
- FullyFunctional 5y ago
  I think you misunderstood what he said and I know he wasn't joking, but I didn't point out that the implied context was for Tenstorrent's usage, thus data center. He didn't mean that you just need six instructions (eg. Turing tarpit), he meant (and he's right) that the bulk of [integer] performance comes from a very small set of instructions, most critically loads and conditional branches. All of the discussed extensions helps specific workloads, but unless your workload is, say, 100% encryption all the time, then the crypto extension will only provide a trivial improvement on the _overall_ performance. Vector is a little bit different, but it (like AVX2/512) comes at a very significant cost and you better have software that can take advantage of it.
  - panick21_ 5y ago
    The whole point of RISC-V is to be a universal architecture used for everything. The idea is to have profiles for different verticals and application. In these profiles you define what extensions you need. If there is really a significant win for a certain type of server workloads, that community will make its own profile and hopefully be able to get chips that utilize that. The problem is that there are also many mixed workloads and having lots of general compute can work pretty well if you want to run a broad set of extinctions. RISC-V is sort of a fluid spectrum from highly specialized to highly general depending on the use case.
aseipp 5y ago
These particular extensions come across as "long-tail" things that are probably worth standardizing, IMO. Not every core needs cryptographic acceleration, but the ones that do need it tend to really need it for those cases. Similarly if you need hypervisor mode support, there are basically no alternatives to just having it, and it requires enough software support to the point you probably have to standardize it, if there's any hope of it working. There's also the advantage that these give a baseline for vendors and software to target instead of rolling their own, within sensibility (though they may choose not to). Some of the other drafted extensions not mentioned here are perhaps more questionable... All three of these are complex enough to definitively increase the design/verification time for any core that implements them, though, that's for sure. (A net effect of this is that while there are tons of simple in-order cores, actual "production" RISC-V cores with features like this will remain rare...)
rektide 5y ago
Your argument is general, but these are very specific areas being served. * RISC-V Vector instructions seem like a huge win for all forms of HPC. x86 is getting vector instructions & the wins have been immense. Rather than a wide range of specific SIMD instructions, vector instructions seem like a far more general & easier to scale up & down implementation strategy. Not everyone has to implement! * RISC-V Hypervisor specifications seem required for modern computing, where VM's are commonplace. Have to have this specification. Not everyone has to implement! * RISC-V Scalar Cryptography specifications providing accelorated cryptography seems like another have to have modern in data-centers. Worth re-iterating what's been said already: extensions are just that: extensions. They're not required. I'm not sure what the current state is, of code detecting & use the accelerated implementation when available, using soft-fallbacks otherwise. For things like cryptography, usually it's a library, openssl or someone, where the library is the reference implementation, with special paths written in for using harware where available.

YorkshireSeason 5y ago

The beauty of a modular instruction set architecture like RISCV's is that you don't have to implement all of it, only the extensions that make sense for your use case. Aside, Keller's quote is probably partly in jest. If you are in a constrained micro-controller environment something like the ZFinx extension is probably helpful beyond the "just six instructions" for code density. If you are crypto heavy, the crypto extension are going to be more helpful than "just six instructions". If your workload is parallelisable and regular, vectorisation helps you more than "just six instructions" and so on. One size doesn't fit all.

bee_rider 5y ago
How does the modular instruction set work? If someone proposes an extension, is the onus on them to also provide a minimal RISCV implementation of that functionality? Or is it just accepted that some binaries won't work on all devices?
- forty 5y ago
  I have no idea for Riscv specifically, but x86/amd64 have a lot of optional instructions (I'm mostly aware of vector stuff like SSE, AVX but I'm sure there are other stuff). On the programming side, you can detect at runtime feature support and use specific code path accordingly, or decide at compile time that you require a specific CPU feature and then your binary will just not work on CPUs without the feature.
- Pet_Ant 5y ago
  > Or is it just accepted that some binaries won't work on all devices? Yes. Just like you cannot run Pentium code on a 386 because they added new extensions. Or how Scheme isn't really a programming language but more like a _family_ of very nearly compatible languagues. RISCV has multiple targets and so so they have very different needs from embedded automotive to desktop. But with a common core is easier to develop and share tooling.
- deleted 5y ago
  [deleted]
- YorkshireSeason 5y ago
  It's best to think of RISCV not as a single ISA (= instruction set architecture), but a parametric ISA. The extensions are parameters. RISCV offers lots of official extensions to choose from, such as M, A, F, D, P, V, .... In addition you have the 32 vs 64 bit data width parameter. Any specific ISA will have to instantiate those parameters, like e.g. so: RISCV32MFP or RISCV64MAF. Any implementation of e.g. RISCV64MAF will have to implement in silicon exactly those assembly command (and supporting features) that the M, A and F extension demand, with 64 bit register width. Like in OO-programming the class constructors take arguments that parameterise the created object. ------ Regarding an implementation, given that RISCV is an ISA, not an ISA implementation, you need to provide a functional model. The official standard is [1] but it's a bit behind the ratified extensions. For example [2] defines the (ISA-visible) registers, while [3] gives you the instruction decoding and execution clause for the most base instruction set. [4] describes part of one of the available address translation modes (for the 32 bit variant of the ISA). Note: in modern processors page-table walks are hardware accelerated, so OS and processor need to use the same format here, which is why this is part of the ISA. [1] https://github.com/riscv/sail-riscv/tree/master/model https://github.com/riscv/sail-riscv/tree/master/model [2] https://github.com/riscv/sail-riscv/blob/master/model/riscv_regs.sail https://github.com/riscv/sail-riscv/blob/master/model/riscv_... [3] https://github.com/riscv/sail-riscv/blob/master/model/riscv_insts_base.sail https://github.com/riscv/sail-riscv/blob/master/model/riscv_... [4] https://github.com/riscv/sail-riscv/blob/master/model/riscv_vmem_sv32.sail https://github.com/riscv/sail-riscv/blob/master/model/riscv_...
- panick21_ 5y ago
  The way it works is that there are profiles. The idea behind profiles is that different use cases define profiles with the instruction extensions the require or are optional and so on. So the major Linux distros agree on a set of instructions and that's called a profile. Same for embedded and others eventually. You can add your own extensions for yourself if you want. You can also make extentions and try to make it a sudo standard. Or you can attempt to make it into a standard extention. To be a standard extension it has to go threw a long process and it will likely be tapped out multiple times before it is ever ratified. Once its ratified it will find its way into profiles. So for example standard Linux distros now use RV64GC, likely the next version of the Linux profile will include more of the new instructions. But yes, the goal is not to create a 'universal binary'. But a reasonable compromise between reuse and specialization.
bsder 5y ago
> One size doesn't fit all. True, but a standard that is too malleable isn't really a standard at all.
- snvzz 5y ago
  If you're building a chip for a server, workstation, laptop, smartphone, then you'll want to adhere to a platform spec profile. RVA22[0] is the first such profile, and among other important things which go a long way to ease cross-vendor software compatibility, it does require RVA22U and RVA22S, which in turn require a set of extensions. [0]: https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc https://github.com/riscv/riscv-platform-specs/blob/main/risc...
- neilalexander 5y ago
  In probably any “open” ISA, vendors/manufacturers are likely to “fork it” and show up with their own extensions anyway. By embracing extensions as a first-class concept, it would seem RISC-V is trying to embrace variance rather than to repeat the mistakes of architectures like amd64 (which has multiple “microarchitecture levels” and only the lowest level is truly portable).
  - panick21_ 5y ago
    To a certain extent yes they embrace variance but to a certain extent they don't. The idea is that what is dominates is software. If you add your own extensions, literally all software in the world wont support it. You will need to provide a huge amount of stuff to fully take advantage of that. The availability of software both open and commercial on top of standardized profiles targets should be what manufacturers target. Early on of course, manufactures have provided things that are not standard yet. However over time, does it really make sense to supply your own bit manipulation extension? As the standard grows the waste majority of application should not require or be really improved by proprietary extensions. Of course if somebody comes along and makes a chip that is just vastly better then what anybody else has with some extensions. That could break that paradigm and people might embrace it.
FullyFunctional 5y ago
I think you misunderstood what he said and I know he wasn't joking, but I didn't point out that the implied context was for Tenstorrent's usage, thus data center. He didn't mean that you just need six instructions (eg. Turing tarpit), he meant (and he's right) that the bulk of [integer] performance comes from a very small set of instructions, most critically loads and conditional branches. All of the discussed extensions helps specific workloads, but unless your workload is, say, 100% encryption all the time, then the crypto extension will only provide a trivial improvement on the _overall_ performance. Vector is a little bit different, but it (like AVX2/512) comes at a very significant cost and you better have software that can take advantage of it.
- panick21_ 5y ago
  The whole point of RISC-V is to be a universal architecture used for everything. The idea is to have profiles for different verticals and application. In these profiles you define what extensions you need. If there is really a significant win for a certain type of server workloads, that community will make its own profile and hopefully be able to get chips that utilize that. The problem is that there are also many mixed workloads and having lots of general compute can work pretty well if you want to run a broad set of extinctions. RISC-V is sort of a fluid spectrum from highly specialized to highly general depending on the use case.

aseipp 5y ago

These particular extensions come across as "long-tail" things that are probably worth standardizing, IMO. Not every core needs cryptographic acceleration, but the ones that do need it tend to really need it for those cases. Similarly if you need hypervisor mode support, there are basically no alternatives to just having it, and it requires enough software support to the point you probably have to standardize it, if there's any hope of it working. There's also the advantage that these give a baseline for vendors and software to target instead of rolling their own, within sensibility (though they may choose not to). Some of the other drafted extensions not mentioned here are perhaps more questionable... All three of these are complex enough to definitively increase the design/verification time for any core that implements them, though, that's for sure. (A net effect of this is that while there are tons of simple in-order cores, actual "production" RISC-V cores with features like this will remain rare...)

rektide 5y ago

Your argument is general, but these are very specific areas being served. * RISC-V Vector instructions seem like a huge win for all forms of HPC. x86 is getting vector instructions & the wins have been immense. Rather than a wide range of specific SIMD instructions, vector instructions seem like a far more general & easier to scale up & down implementation strategy. Not everyone has to implement! * RISC-V Hypervisor specifications seem required for modern computing, where VM's are commonplace. Have to have this specification. Not everyone has to implement! * RISC-V Scalar Cryptography specifications providing accelorated cryptography seems like another have to have modern in data-centers. Worth re-iterating what's been said already: extensions are just that: extensions. They're not required. I'm not sure what the current state is, of code detecting & use the accelerated implementation when available, using soft-fallbacks otherwise. For things like cryptography, usually it's a library, openssl or someone, where the library is the reference implementation, with special paths written in for using harware where available.