4 ms·

Newsflash: people who made different decisions on their own designs think they made the right decision. Update at 9. ISAs without condition codes have been aro

Newsflash: people who made different decisions on their own designs think they made the right decision. Update at 9. ISAs without condition codes have been around for a long time, and very technically successful. MIPS and DEC Alpha, for example. (both killed by clueless management, not any technical issue) The vast vast majority of condition code updates are either never used at all or are used by the very next instruction. In either case, there is little point in reifying them and no point in saving them. Generating a condition a few instructions before it is used happens from time to time, at least on ISAs where only some instruction types update the condition codes, or there is a flag in the instruction to indicate whether to or not. An ISA without condition codes but with plenty of registers can do the same thing using SLT/SLTU (Set if Less Than [Unsigned]) to generate a 0 or 1 in a normal register. Or a simple XOR or SUB for equality tests. Historically, use of condition codes is because your instructions aren't big enough to contain two source operands, a test, and a reasonable branch offset. Now it's because you're descended from such an ISA. Similarly, many early ISAs did conditional skip instead of conditional branch because their instructions weren't big enough to test a condition and also hold a useful branch offset. Some of them could integrate a compare with the skip, but some of them needed three instructions: compare -> CCs; skip based on CCs; jump. Not high performance. Compare and branch, all in one instruction, is best most of the time if you have the opcode space for it.

ncmncm 5y ago
People who have designed other systems can point out many of their own mistakes, too. Being unable to spot any should inspire less confidence, not more. Setting a 0 or 1 in SLT was another design error. People designing GPUs demonstrate that they know the better design sets a 0 or ~0 (all ones). Huge instructions have been regretted enough to motivate abbreviated versions. Even in RISC-V. And, as has already been noted in this forum, lack of a reliably available popcount instruction has been subsequently corrected, at great expense, practically everywhere. All of which really only means I'm ready for Risc-6. With some care, it should be able to re-use much of the ecosystem work from RISC-V.
- zozbot234 5y ago
  > Setting a 0 or 1 in SLT was another design error. People designing GPUs demonstrate that they know the better design sets a 0 or ~0 (all ones). Going from 0/1 to 0/~0 (or conversely) just takes a NEG instruction. All in all, it's a trivial difference. And it's hard to say what's more convenient in actual code.
  - ncmncm 5y ago
    "Just takes" is another way to say "takes". And, when all your instructions are at least 4 bytes, that takes another 4 bytes.
- brucehoult 5y ago
  I completely agree with you on 0/1 vs 0/-1 for SLT and you can easily find me saying so. For example: https://lists.riscv.org/g/tech-bitmanip/message/496 https://lists.riscv.org/g/tech-bitmanip/message/496 It was an error, though a rather minor one, to follow the C language so closely. I can and have pointed out other minor mistakes in RISC-V in the past -- none of them serious enough to abandon it and start over. I'll quote myself from there, below. 32 bits is not such a huge instruction. ARM decided it's good enough for their new(ish) 64 bit ISA, and it's about the average size of x86_64 instructions. Original RISC-V (v1.0) has only and exactly the instructions needed to implement C. That's enough for many or most applications, and will be available as a support option forever. The upcoming RVA22 specification for Applications Processors, which will be ratified before the end of the year includes an SVE-like vector extension and also Bit Manipulation extensions (along with many others). The Zbb (Basic bit-manipulation) extension includes cpop along with clz and ctz and rotate. There is also andn, orn, xnor, max, maxu, min, minu, sext.b, sext.h, zext.h, and rev8 (reverse bytes in a register). Plus a unique instruction orc.b which replaces any non-zero byte in the source operand with all ones. There is also scalar crypto and cache manipulation (prefetch, flush etc). Perhaps RVA22 is your hypothetical Risc-6. ----- There are five reasons you might use SLT / SLTU, in (I think) descending order of how common they are, and the implications had -1 been used instead of 1: 1) to generate a zero/non-zero value. No difference. 2) to generate a mask. Using 0 and -1 is better, saving a NEG or a subtract 1, depending on whether you reverse the condition or not. 3) to generate a value that can be AND / OR / XOT etc with other such values. No difference. 4) to assign to a canonical C/C++ true/false, or mix with them using AND / OR / XOR. Worse -- have to do an ANDI #1 before using the final result. 5) to generate a canonical C true/false and add or subtract it from something. No difference. Just flip add to subtract or vice versa. Interestingly, a time when you do want 0 or 1 is the examples in the original superoptimiser paper from 1987. https://web.stanford.edu/class/cs343/resources/superoptimizer.pdf https://web.stanford.edu/class/cs343/resources/superoptimize... They first considered the function: int signum (int x) { if(x > 0) return I; else if(x < 0} return -I; else return 0; ) They showed the superoptimiser finding the following unexpected 68020 sequence, making use of the carry flag: (x in dO) add.l d0,d0 ;add dO to itself subx.l dl,dl ;subtract (dl + Carry) from dl negx.l dO ;put (0 - dO - Carry) into dO addx.l dl,dl ;add (dl + Carry) to dl (signum(x) in dl} (4 instructions} This is much more straightforward on RISC-V: (x in a0) slt a1,a0,zero # a1 = 1 if x is negative, 0 if 0 or positive slt a0,zero,a0 # a0 = 1 if x is positive, 0 if 0 or negative sub a0,a0,a1 # 1-0 = 1 if positive, 0-0 = 0 if zero, 0-1 = -1 if negative -----
throwaway81523 5y ago
The "1980's called" issue that always gets to me is the absence of arithmetic overflow (or divide by 0) detection. You end up having to generate several additional instructions if you want to catch those errors (-trapv in gcc). On other architectures that's done with condition flags or traps. This doesn't apply to floating point, where condition flags (confusingly called exceptions in IEEE parlance) are mandated by IEEE 857 and afaik Risc-V implements them conformantly. I don't see why they couldn't also do something like that for integers.
- GoblinSlayer 5y ago
  I guess you use this mode when your application is IO bound.

ncmncm 5y ago

People who have designed other systems can point out many of their own mistakes, too. Being unable to spot any should inspire less confidence, not more. Setting a 0 or 1 in SLT was another design error. People designing GPUs demonstrate that they know the better design sets a 0 or ~0 (all ones). Huge instructions have been regretted enough to motivate abbreviated versions. Even in RISC-V. And, as has already been noted in this forum, lack of a reliably available popcount instruction has been subsequently corrected, at great expense, practically everywhere. All of which really only means I'm ready for Risc-6. With some care, it should be able to re-use much of the ecosystem work from RISC-V.

zozbot234 5y ago
> Setting a 0 or 1 in SLT was another design error. People designing GPUs demonstrate that they know the better design sets a 0 or ~0 (all ones). Going from 0/1 to 0/~0 (or conversely) just takes a NEG instruction. All in all, it's a trivial difference. And it's hard to say what's more convenient in actual code.
- ncmncm 5y ago
  "Just takes" is another way to say "takes". And, when all your instructions are at least 4 bytes, that takes another 4 bytes.
brucehoult 5y ago
I completely agree with you on 0/1 vs 0/-1 for SLT and you can easily find me saying so. For example: https://lists.riscv.org/g/tech-bitmanip/message/496 https://lists.riscv.org/g/tech-bitmanip/message/496 It was an error, though a rather minor one, to follow the C language so closely. I can and have pointed out other minor mistakes in RISC-V in the past -- none of them serious enough to abandon it and start over. I'll quote myself from there, below. 32 bits is not such a huge instruction. ARM decided it's good enough for their new(ish) 64 bit ISA, and it's about the average size of x86_64 instructions. Original RISC-V (v1.0) has only and exactly the instructions needed to implement C. That's enough for many or most applications, and will be available as a support option forever. The upcoming RVA22 specification for Applications Processors, which will be ratified before the end of the year includes an SVE-like vector extension and also Bit Manipulation extensions (along with many others). The Zbb (Basic bit-manipulation) extension includes cpop along with clz and ctz and rotate. There is also andn, orn, xnor, max, maxu, min, minu, sext.b, sext.h, zext.h, and rev8 (reverse bytes in a register). Plus a unique instruction orc.b which replaces any non-zero byte in the source operand with all ones. There is also scalar crypto and cache manipulation (prefetch, flush etc). Perhaps RVA22 is your hypothetical Risc-6. ----- There are five reasons you might use SLT / SLTU, in (I think) descending order of how common they are, and the implications had -1 been used instead of 1: 1) to generate a zero/non-zero value. No difference. 2) to generate a mask. Using 0 and -1 is better, saving a NEG or a subtract 1, depending on whether you reverse the condition or not. 3) to generate a value that can be AND / OR / XOT etc with other such values. No difference. 4) to assign to a canonical C/C++ true/false, or mix with them using AND / OR / XOR. Worse -- have to do an ANDI #1 before using the final result. 5) to generate a canonical C true/false and add or subtract it from something. No difference. Just flip add to subtract or vice versa. Interestingly, a time when you do want 0 or 1 is the examples in the original superoptimiser paper from 1987. https://web.stanford.edu/class/cs343/resources/superoptimizer.pdf https://web.stanford.edu/class/cs343/resources/superoptimize... They first considered the function: int signum (int x) { if(x > 0) return I; else if(x < 0} return -I; else return 0; ) They showed the superoptimiser finding the following unexpected 68020 sequence, making use of the carry flag: (x in dO) add.l d0,d0 ;add dO to itself subx.l dl,dl ;subtract (dl + Carry) from dl negx.l dO ;put (0 - dO - Carry) into dO addx.l dl,dl ;add (dl + Carry) to dl (signum(x) in dl} (4 instructions} This is much more straightforward on RISC-V: (x in a0) slt a1,a0,zero # a1 = 1 if x is negative, 0 if 0 or positive slt a0,zero,a0 # a0 = 1 if x is positive, 0 if 0 or negative sub a0,a0,a1 # 1-0 = 1 if positive, 0-0 = 0 if zero, 0-1 = -1 if negative -----

throwaway81523 5y ago

The "1980's called" issue that always gets to me is the absence of arithmetic overflow (or divide by 0) detection. You end up having to generate several additional instructions if you want to catch those errors (-trapv in gcc). On other architectures that's done with condition flags or traps. This doesn't apply to floating point, where condition flags (confusingly called exceptions in IEEE parlance) are mandated by IEEE 857 and afaik Risc-V implements them conformantly. I don't see why they couldn't also do something like that for integers.

GoblinSlayer 5y ago
I guess you use this mode when your application is IO bound.