5 ms·

The usual RISC-V FUD points. It gets boring. >It has a soup of wacky opcodes to optimize corner cases OK, go ahead and name one (1) such opcode. I'll wait. >

by snvzz 3y ago

The usual RISC-V FUD points. It gets boring. >It has a soup of wacky opcodes to optimize corner cases OK, go ahead and name one (1) such opcode. I'll wait. >obscure vendor specific extensions that are absolutely CISC-y (examine T-Head's additions if you don't believe me!). Yes, these extensions are harmful, and that's why they're obscure and vendor-specific. RISC-V considers pros and cons, evaluates across use cases, and weights everything when considering whether to accept something into the standard specs. Simplicity itself is valuable; that is at the core of RISC. So the default is to reject. A strong argument needs to be made to justify adding anything.

codedokode 3y ago
RISC-V ISA is very inconsistent. For example, for addition with checked overflow the spec says that there is no need for such instruction as it can be implemented "cheaply" in four instructions. But at the same time they have fused multiply-add which is only needed for matrix multiplication (i.e. only for scientific software), which is difficult to implement (it needs to read 3 registers at once), and which can be easily replaced with two separate instructions.
- brucehoult 3y ago
  Fused floating point multiply-add with a single rounding from the infinite-precision answer is required by the IEEE 754-2008 floating point standard. You don't get a choice in the matter. > can be easily replaced with two separate instructions It can't. You will get different answers. RISC-V allows you to choose a CPU without floating point instructions. But if you choose to have an FPU then you get multipy-add. Yes, it needs to read three registers, which is expensive. It is also the most common instruction in any floating point calculation, so that expensive three port register file gets used constantly. Checking overflow for addition on the other hand is something that is very seldom used (on any CPU). On RISC-V you need four instructions only if the operands are full register size and you don't know anything about either operand. If you know the sign of one operand then the cost reduces to one extra instruction.
  - skissane 3y ago
    > Checking overflow for addition on the other hand is something that is very seldom used (on any CPU) I think a lot of that is due to the popularity of C, and the fact that C has no built-in support for overflow checking. In some alternate timeline in which C had that feature (or a different language which had that feature took C's place), I suspect it would have been used a fair bit more often. Well C23 finally adds checked arithmetic, in <stdckdint.h>. But, it took until 2023 to do it, what if it had been there 20, 30, 40 years ago? Very little software supports it yet anyway. And it isn't using the same syntax as standard arithmetic. Instead of `c = a + b`, you have to do `ckd_add(&c, a, b)`. That isn't going to encourage people to use it.
    - codedokode 3y ago
      Yes the ugliness of the syntax for checked addition overweighs benefits like better accuracy and security from using it.
  - codedokode 3y ago
    > Checking overflow for addition on the other hand is something that is very seldom used (on any CPU). I believe you are wrong. Almost every addition used in software should be a proper addition, not addition module 2^32 or 2^64. For example, if you want to calculate total for customer's order, you want proper addition, not a remainder after division by 2^32. Or if you are calculating a number of visitors of a website, again, you need the correct number. Addition modulo N is used only in niche cases like cryptography. In my opinion, it is wrapping addition which is seldomly used. I can't remember last time when I needed it. So it is surprising that RISC-V makes rarely used operation take less instructions than more popular one. You might argue, that some poorly designed ancient languages have '+' operator to perform wrapping addition, however that is only because they are poorly designed, not because users want such method of addition. For comparison, a properly designed language, Swift has non-wrapping addition.
    - defrost 3y ago
      > Addition modulo N is used only in niche cases like cryptography. ... and niche cases like GIS location computations on a spherical planet and any form of engineering | physics mesh computation. It's inescapable when you peer into the guts of any earth based modelling from satellte data .. something that happens on a daily terrabyte scale.
deleted 3y ago
[deleted]
0xr0kk3r 3y ago
[flagged]
- ghusbands 3y ago
  You're missing the point. You said "The ISA [and ratified extensions] has a soup of wacky opcodes". You're being asked to name a single wacky opcode from the ISA and ratified extensions. The response mentioned only vendor-specific extensions having bad opcodes.
  - 0xr0kk3r 3y ago
    The reply is an obvious troll. Whenever someone yawns at your post, dismisses, and then decides to be the arbiter of what constitutes valid (classic fallacy), walk away. Proof? Others did reply and Op just pisses on them verbally. If you don’t know how to read the ratified extensions which OP admitted we’re harmful, just walk away from the topic.
    - ghusbands 3y ago
      As an interested observer, I would like to know more about what you're talking about - it's not trivial to find the T-Head RISC-V extensions or identify which ratified extensions are 'wacky opcodes' or related. I agree that the OP has a biased view in favour of RISC-V, but it's also natural to react strongly to attacks like "soup of wacky opcodes". I can see that RISC-V has made some short-sighted decisions (like having no carry flag or equivalent), and has a good few ratified extensions. But how does it compare to other architectures? I think everyone would agree that x86/x64 is a soup of wacky opcodes; is modern ARM(+SVE) better than RISC-V in this regard?
      - brucehoult 3y ago
        Why is having no carry flag "short-sighted"? Rather, it is dropping the unneeded historical baggage. A carry flag was useful on an 8 bit CPU where you were constantly dealing with 16 bit and 32 bit numbers. On a 64 bit CPU it is almost never used, and updating it on every add is an absolute waste of resources.
saagarjha 3y ago
I’d be bored too if I showed up in RISC-V threads to read “FUD” into any comment that doesn’t immediately praise every aspect of the architecture.
deleted 3y ago
[deleted]

by snvzz 3y ago

codedokode 3y ago

RISC-V ISA is very inconsistent. For example, for addition with checked overflow the spec says that there is no need for such instruction as it can be implemented "cheaply" in four instructions. But at the same time they have fused multiply-add which is only needed for matrix multiplication (i.e. only for scientific software), which is difficult to implement (it needs to read 3 registers at once), and which can be easily replaced with two separate instructions.

brucehoult 3y ago
Fused floating point multiply-add with a single rounding from the infinite-precision answer is required by the IEEE 754-2008 floating point standard. You don't get a choice in the matter. > can be easily replaced with two separate instructions It can't. You will get different answers. RISC-V allows you to choose a CPU without floating point instructions. But if you choose to have an FPU then you get multipy-add. Yes, it needs to read three registers, which is expensive. It is also the most common instruction in any floating point calculation, so that expensive three port register file gets used constantly. Checking overflow for addition on the other hand is something that is very seldom used (on any CPU). On RISC-V you need four instructions only if the operands are full register size and you don't know anything about either operand. If you know the sign of one operand then the cost reduces to one extra instruction.
- skissane 3y ago
  > Checking overflow for addition on the other hand is something that is very seldom used (on any CPU) I think a lot of that is due to the popularity of C, and the fact that C has no built-in support for overflow checking. In some alternate timeline in which C had that feature (or a different language which had that feature took C's place), I suspect it would have been used a fair bit more often. Well C23 finally adds checked arithmetic, in <stdckdint.h>. But, it took until 2023 to do it, what if it had been there 20, 30, 40 years ago? Very little software supports it yet anyway. And it isn't using the same syntax as standard arithmetic. Instead of `c = a + b`, you have to do `ckd_add(&c, a, b)`. That isn't going to encourage people to use it.
  - codedokode 3y ago
    Yes the ugliness of the syntax for checked addition overweighs benefits like better accuracy and security from using it.
- codedokode 3y ago
  > Checking overflow for addition on the other hand is something that is very seldom used (on any CPU). I believe you are wrong. Almost every addition used in software should be a proper addition, not addition module 2^32 or 2^64. For example, if you want to calculate total for customer's order, you want proper addition, not a remainder after division by 2^32. Or if you are calculating a number of visitors of a website, again, you need the correct number. Addition modulo N is used only in niche cases like cryptography. In my opinion, it is wrapping addition which is seldomly used. I can't remember last time when I needed it. So it is surprising that RISC-V makes rarely used operation take less instructions than more popular one. You might argue, that some poorly designed ancient languages have '+' operator to perform wrapping addition, however that is only because they are poorly designed, not because users want such method of addition. For comparison, a properly designed language, Swift has non-wrapping addition.
  - defrost 3y ago
    > Addition modulo N is used only in niche cases like cryptography. ... and niche cases like GIS location computations on a spherical planet and any form of engineering | physics mesh computation. It's inescapable when you peer into the guts of any earth based modelling from satellte data .. something that happens on a daily terrabyte scale.

deleted 3y ago

[deleted]

0xr0kk3r 3y ago

[flagged]

ghusbands 3y ago
You're missing the point. You said "The ISA [and ratified extensions] has a soup of wacky opcodes". You're being asked to name a single wacky opcode from the ISA and ratified extensions. The response mentioned only vendor-specific extensions having bad opcodes.
- 0xr0kk3r 3y ago
  The reply is an obvious troll. Whenever someone yawns at your post, dismisses, and then decides to be the arbiter of what constitutes valid (classic fallacy), walk away. Proof? Others did reply and Op just pisses on them verbally. If you don’t know how to read the ratified extensions which OP admitted we’re harmful, just walk away from the topic.
  - ghusbands 3y ago
    As an interested observer, I would like to know more about what you're talking about - it's not trivial to find the T-Head RISC-V extensions or identify which ratified extensions are 'wacky opcodes' or related. I agree that the OP has a biased view in favour of RISC-V, but it's also natural to react strongly to attacks like "soup of wacky opcodes". I can see that RISC-V has made some short-sighted decisions (like having no carry flag or equivalent), and has a good few ratified extensions. But how does it compare to other architectures? I think everyone would agree that x86/x64 is a soup of wacky opcodes; is modern ARM(+SVE) better than RISC-V in this regard?
    - brucehoult 3y ago
      Why is having no carry flag "short-sighted"? Rather, it is dropping the unneeded historical baggage. A carry flag was useful on an 8 bit CPU where you were constantly dealing with 16 bit and 32 bit numbers. On a 64 bit CPU it is almost never used, and updating it on every add is an absolute waste of resources.

saagarjha 3y ago

I’d be bored too if I showed up in RISC-V threads to read “FUD” into any comment that doesn’t immediately praise every aspect of the architecture.

deleted 3y ago

[deleted]