4 ms·

By definition, RISC stands for "reduced instruction set computer". And RISC-V exposes its internals so it has way more instructions than a conventional CISC pro

By definition, RISC stands for "reduced instruction set computer". And RISC-V exposes its internals so it has way more instructions than a conventional CISC processor, a lot of which deal with its internal states. Here is a good example[1]: For general signed addition, three additional instructions after the addition are required, leveraging the observation that the sum should be less than one of the operands if and only if the other operand is negative. add t0, t1, t2 slti t3, t2, 0 slt t4, t0, t1 bne t3, t4, overflow ...good luck programming this insane design with anything other than a high level language compiler. [1] https://riscv.org/specifications/ https://riscv.org/specifications/

avianes 7y ago
> And RISC-V exposes its internals But your example shows no internal states exposure, it's just arithmetic to detect overflow. What are you trying to show ?
Symmetry 7y ago
Generally, the "reduced instruction set" in RISC refers to how many instructions are available to the programmer, i.e. not many, rather than the larger number of instructions it then takes to accomplish anything. And the difficulty isn't really about exposing the internals, this isn't like a branch delay slot for instance. It's about making the relationship between instructions conceptually simple where there's always up to 2 inputs and up to one output. That doesn't help much in cases where the processor is doing something close to what the instructions are saying but it makes the simplest possible out of order processor, where the internals diverge wildly from the ISA, much easier to create. EDIT: Also, the using C and compiling rather than doing assembly by hand is really a fundamental part of the whole RISC philosophy and RISC-V is just a more extreme form of that.
- msla 7y ago
  The Reduced means that the instructions themselves are reduced, as in easier to implement and easier to implement in a pipelined implementation. As opposed to having instructions with plenty of addressing modes, you have a lot of register-register instructions and load and store opcodes: You compute the addresses explicitly, using the register-register opcodes, then load from that address using a load opcode which doesn't do much ALU work, then work on the loaded value in the registers. Contrast this with a leading CISC design, the VAX, which had plenty of addressing modes which practically all opcodes could use. A single opcode could expand into a whole stream of micro-operations to compute the addresses being loaded from, actually perform the named opcode, and then compute the address being stored to, and possibly more. Doing that in the presence of virtual memory, where an opcode might have to be stopped and restarted so the OS could take a page fault, was rather nontrivial. https://link.springer.com/chapter/10.1007%2F0-387-27446-4_3 https://link.springer.com/chapter/10.1007%2F0-387-27446-4_3
sligor 7y ago
That's main problem of RISC-V ISA: doing multi-precision arithmetic needs to do branching. It is not only a programming complexity issue, it is then very difficult to do large number arithmetic in constant-time due to the branch predictors of modern CPUs. This can create timing-attacks problems (side-channel attacks) in algorithms like RSA. But that's the only big issue, saying that the whole ISA is insane due to this specific point of design is totally overstated
- rwmj 7y ago
  And also if it's important to someone to fix this, then extensions will be proposed for multi-precision arithmetic and constant time crypto primitives. RISC-V is an extensible architecture for this very reason.
- justincormack 7y ago
  I don't think you need branches, you can just add in the output of the correct lte (which returns 0 or 1) as the extra carry in.
  - Annatar 7y ago
    Was that even English? You know processors aren't supposed to be this difficult that your skull explodes, correct?
    - Taniwha 7y ago
      doesn't matter if the compiler understands it
    - rstuart4133 7y ago
      Perhaps not normal English. But to those of us who have written a lot of assembler is was plain enough. Every heard two medical doctors discuss a patient? It's the same phenomenon. Every processor architecture (and computer language for that matter) has it's own idiosyncrasies, every assembler programmer builds up a repertoire of sequences for handling them over time. It was plain he was giving you one of those sequences, and it is pretty obvious how to apply it. Oh, and to answer your question: being simple to understand is _not_ a design criterion for processors. We've been there, done that with the VAX and later the iAPX32. It wasn't a success. We've since settled on what they are supposed to be: efficient in terms of silicon and power consumption. Architectures that win those races will be here in the long term. The VAX and iAPX32 were poor at it, and died. x86 is grimly holding onto it's niche, but I don't expect that to last. It has already lost the consumer market as most consumers use ARM now.
pjc50 7y ago
You left out the paragraph introducing this in the footnote: > We did not include special instruction-set support for overflow checks on integer arithmetic operations in the base instruction set, as many overflow checks can be cheaply implemented using RISC-V branches. So this boils down to "there's no platform overflow (V) flag", which is also a problem on other RISC systems, and is in any case rarely used in C code because it doesn't check for overflow.
- Annatar 7y ago
  I didn't want to unduly burden the audience here, so they don't get an aneurism and end up on n-gate.com webshit weekly. The fact that this processor design has no state register just cements my point that its designers were insane, as is plain to see from the nonsense instructions one has to write to get basic things done. Assembler is supposed to be simple, not a retarded masturbation.
- Taniwha 7y ago
  yes, exactly - if you want to add 2 registers use: add t0, t1, t2 in the occasional case where you want overflow as well add the other 3 instructions - if you're hand coding in assembler you probably know which you want, if you're using a compiler, it can map it's semantics where appropriate
msla 7y ago
> good luck programming this insane design with anything other than a high level language compiler. That's been the RISC idea from day one. CISC ISAs were nice to the assembly programmer, RISC ISAs were nice to the C programmer and the hardware implementer. Do you know how to do integer multiplication on the MIPS? I'll tell you: li $a0, 5 li $a1, 6 mult $a0, $a1 ... do some other stuff here ... mfhi $a2 mflo $v0 Why do you want to do other stuff? What's that mfhi and mflo stuff? Why is mult not three-operand? Because RISC! The MIPS model is so RISCy it exposes the fact its multiplication isn't single-cycle. It does this by making it somewhat asynchronous: You issue the multiplication opcode, and your code continues to run while the arithmetic is performed. If you try to get the result immediately, you'll stall the pipeline, so you were encouraged to schedule opcodes that don't rely on the result of the multiplication to run in that hazard. In a CISC chip, that would have been handled by microcode, and you would have gotten nice three-operand multiplication opcodes which could even do memory-to-memory operations, like on the VAX. In a RISC chip, the compiler was assumed to have all the intelligence the microcode used to have, so you got simpler-and-supposedly-faster hardware with really funky assembly language behavior. https://devblogs.microsoft.com/oldnewthing/20180404-00/?p=98435 https://devblogs.microsoft.com/oldnewthing/20180404-00/?p=98... TL;DR: Compared to the MIPS, RISC-V is a model of rationality and clarity.
- Annatar 7y ago
  Yeah... no. I'd rather bang my head against the wall until it bleeds profusely and I figure out how to synthesize my own OpenSPARC cores and enjoy myself on 64-bit MC68080 which gets faster and faster with every accelerator update.
  - snvzz 7y ago
    >enjoy myself on 64-bit MC68080 which gets faster and faster with every accelerator update. Note that Apollo Core isn't OSHW, so you won't be synthesizing that one.
    - Annatar 7y ago
      I don't need to, as I don't masturbate on such things and the Apollo team knows what they are doing. Those guys are competent, and that's what matters to me.
rstuart4133 7y ago
That's harsh. Have you written much assembler? If so, how often did you need to check for overflow? (I've written quite a bit of it, and the number of times I've checked the overflow bit in the x86's flags could be counted on one hand.) In the unlikely event you did need to check for overflow frequently, wouldn't you write a macro to generate the required instructions? Compared to the earlier CPU's like Z80's, or god help us DSP's and GPU's, this thing an absolute delight. In fact even compared to x86, it's a model of clarity. Have you ever looked at the Intel architecture manuals for x86? The description of how a "jmp" operates runs for pages and pages of pseudo code. I'll guess you will counter "but most people don't use the more complex features like gates", but the reality is I've used jumps via gates far more times than I've tested for overflow - and I've had to digest those pages and pages of pesudo code and the related data structures many times because they are so damned complex and unintuitive you keep forgetting the details.
- Annatar 7y ago
  "Have you written much assembler?" I have written lots of MOS6502, MC68000 and UltraSPARC assembler, as I come from the demo and cracking scene. That's where I grew up.

avianes 7y ago

> And RISC-V exposes its internals But your example shows no internal states exposure, it's just arithmetic to detect overflow. What are you trying to show ?

Symmetry 7y ago

Generally, the "reduced instruction set" in RISC refers to how many instructions are available to the programmer, i.e. not many, rather than the larger number of instructions it then takes to accomplish anything. And the difficulty isn't really about exposing the internals, this isn't like a branch delay slot for instance. It's about making the relationship between instructions conceptually simple where there's always up to 2 inputs and up to one output. That doesn't help much in cases where the processor is doing something close to what the instructions are saying but it makes the simplest possible out of order processor, where the internals diverge wildly from the ISA, much easier to create. EDIT: Also, the using C and compiling rather than doing assembly by hand is really a fundamental part of the whole RISC philosophy and RISC-V is just a more extreme form of that.

msla 7y ago
The Reduced means that the instructions themselves are reduced, as in easier to implement and easier to implement in a pipelined implementation. As opposed to having instructions with plenty of addressing modes, you have a lot of register-register instructions and load and store opcodes: You compute the addresses explicitly, using the register-register opcodes, then load from that address using a load opcode which doesn't do much ALU work, then work on the loaded value in the registers. Contrast this with a leading CISC design, the VAX, which had plenty of addressing modes which practically all opcodes could use. A single opcode could expand into a whole stream of micro-operations to compute the addresses being loaded from, actually perform the named opcode, and then compute the address being stored to, and possibly more. Doing that in the presence of virtual memory, where an opcode might have to be stopped and restarted so the OS could take a page fault, was rather nontrivial. https://link.springer.com/chapter/10.1007%2F0-387-27446-4_3 https://link.springer.com/chapter/10.1007%2F0-387-27446-4_3

sligor 7y ago

That's main problem of RISC-V ISA: doing multi-precision arithmetic needs to do branching. It is not only a programming complexity issue, it is then very difficult to do large number arithmetic in constant-time due to the branch predictors of modern CPUs. This can create timing-attacks problems (side-channel attacks) in algorithms like RSA. But that's the only big issue, saying that the whole ISA is insane due to this specific point of design is totally overstated

rwmj 7y ago
And also if it's important to someone to fix this, then extensions will be proposed for multi-precision arithmetic and constant time crypto primitives. RISC-V is an extensible architecture for this very reason.
justincormack 7y ago
I don't think you need branches, you can just add in the output of the correct lte (which returns 0 or 1) as the extra carry in.
- Annatar 7y ago
  Was that even English? You know processors aren't supposed to be this difficult that your skull explodes, correct?
  - Taniwha 7y ago
    doesn't matter if the compiler understands it
  - rstuart4133 7y ago
    Perhaps not normal English. But to those of us who have written a lot of assembler is was plain enough. Every heard two medical doctors discuss a patient? It's the same phenomenon. Every processor architecture (and computer language for that matter) has it's own idiosyncrasies, every assembler programmer builds up a repertoire of sequences for handling them over time. It was plain he was giving you one of those sequences, and it is pretty obvious how to apply it. Oh, and to answer your question: being simple to understand is _not_ a design criterion for processors. We've been there, done that with the VAX and later the iAPX32. It wasn't a success. We've since settled on what they are supposed to be: efficient in terms of silicon and power consumption. Architectures that win those races will be here in the long term. The VAX and iAPX32 were poor at it, and died. x86 is grimly holding onto it's niche, but I don't expect that to last. It has already lost the consumer market as most consumers use ARM now.

pjc50 7y ago

You left out the paragraph introducing this in the footnote: > We did not include special instruction-set support for overflow checks on integer arithmetic operations in the base instruction set, as many overflow checks can be cheaply implemented using RISC-V branches. So this boils down to "there's no platform overflow (V) flag", which is also a problem on other RISC systems, and is in any case rarely used in C code because it doesn't check for overflow.

Annatar 7y ago
I didn't want to unduly burden the audience here, so they don't get an aneurism and end up on n-gate.com webshit weekly. The fact that this processor design has no state register just cements my point that its designers were insane, as is plain to see from the nonsense instructions one has to write to get basic things done. Assembler is supposed to be simple, not a retarded masturbation.
Taniwha 7y ago
yes, exactly - if you want to add 2 registers use: add t0, t1, t2 in the occasional case where you want overflow as well add the other 3 instructions - if you're hand coding in assembler you probably know which you want, if you're using a compiler, it can map it's semantics where appropriate

msla 7y ago

> good luck programming this insane design with anything other than a high level language compiler. That's been the RISC idea from day one. CISC ISAs were nice to the assembly programmer, RISC ISAs were nice to the C programmer and the hardware implementer. Do you know how to do integer multiplication on the MIPS? I'll tell you: li $a0, 5 li $a1, 6 mult $a0, $a1 ... do some other stuff here ... mfhi $a2 mflo $v0 Why do you want to do other stuff? What's that mfhi and mflo stuff? Why is mult not three-operand? Because RISC! The MIPS model is so RISCy it exposes the fact its multiplication isn't single-cycle. It does this by making it somewhat asynchronous: You issue the multiplication opcode, and your code continues to run while the arithmetic is performed. If you try to get the result immediately, you'll stall the pipeline, so you were encouraged to schedule opcodes that don't rely on the result of the multiplication to run in that hazard. In a CISC chip, that would have been handled by microcode, and you would have gotten nice three-operand multiplication opcodes which could even do memory-to-memory operations, like on the VAX. In a RISC chip, the compiler was assumed to have all the intelligence the microcode used to have, so you got simpler-and-supposedly-faster hardware with really funky assembly language behavior. https://devblogs.microsoft.com/oldnewthing/20180404-00/?p=98435 https://devblogs.microsoft.com/oldnewthing/20180404-00/?p=98... TL;DR: Compared to the MIPS, RISC-V is a model of rationality and clarity.

Annatar 7y ago
Yeah... no. I'd rather bang my head against the wall until it bleeds profusely and I figure out how to synthesize my own OpenSPARC cores and enjoy myself on 64-bit MC68080 which gets faster and faster with every accelerator update.
- snvzz 7y ago
  >enjoy myself on 64-bit MC68080 which gets faster and faster with every accelerator update. Note that Apollo Core isn't OSHW, so you won't be synthesizing that one.
  - Annatar 7y ago
    I don't need to, as I don't masturbate on such things and the Apollo team knows what they are doing. Those guys are competent, and that's what matters to me.

rstuart4133 7y ago

That's harsh. Have you written much assembler? If so, how often did you need to check for overflow? (I've written quite a bit of it, and the number of times I've checked the overflow bit in the x86's flags could be counted on one hand.) In the unlikely event you did need to check for overflow frequently, wouldn't you write a macro to generate the required instructions? Compared to the earlier CPU's like Z80's, or god help us DSP's and GPU's, this thing an absolute delight. In fact even compared to x86, it's a model of clarity. Have you ever looked at the Intel architecture manuals for x86? The description of how a "jmp" operates runs for pages and pages of pseudo code. I'll guess you will counter "but most people don't use the more complex features like gates", but the reality is I've used jumps via gates far more times than I've tested for overflow - and I've had to digest those pages and pages of pesudo code and the related data structures many times because they are so damned complex and unintuitive you keep forgetting the details.

Annatar 7y ago
"Have you written much assembler?" I have written lots of MOS6502, MC68000 and UltraSPARC assembler, as I come from the demo and cracking scene. That's where I grew up.