3 ms·

RISC is ((reduced instruction) set computing), not (reduced (instruction set) computing). That is, the instructions are what's reduced, not the set. What makes

by amyjess 11y ago

RISC is ((reduced instruction) set computing), not (reduced (instruction set) computing). That is, the instructions are what's reduced, not the set. What makes an ISA RISC or CISC is how simple or complex each individual instruction is, not how many instructions are in the set. The point of RISC is that each instruction does one thing and only one thing. There's no addressing modes where a single instruction can access memory, perform some operation on the contents, and write it back into memory. This is why RISC is sometimes described as a strict load/store architecture.

cbd1984 11y ago
RISC is also often described as register-register, as opposed to register-memory or stack or accumulator-based. In a pure register-register design, all opcodes which use the ALU only operate on data stored in registers, and only store data to registers. Due to this, the only opcodes which touch RAM in such a design are load and store opcodes, and they only use the simplest addressing modes. In a register-memory design, ALU-using opcodes can touch RAM as well. This is taken to an extreme in accumulator-based designs, which aren't used much now but were previously very popular: One "main" register which is involved in all (or nearly all) opcodes, maybe a couple index registers to make memory addressing easier, and everything else is in RAM. The 6502 is the prototypical accumulator-based design, with the interesting twist that its zero page (all memory addresses with a high byte of 0x00) is almost as fast as registers, making it practically a machine with 256 one-byte registers. (Stack machines are fairly self-explanatory. I think they're mostly VMs now, because it's easy to take stack machine code, turn it back into a parse tree, and then compile that to optimized machine code.) Register-register designs are typically RISC, which implies constant-size opcodes (one machine word per) to save on decoding hardware, pipelining built in from the start (so no or few complicated opcodes which can take an unpredictable number of cycles to complete), and a very Spartan design philosophy, even to the extent of making the pipelining architecturally visible by specifying things like branch delay slots (where the opcode immediately after a taken branch opcode is still executed, because it's already in the pipeline). The idea was that the compiler would make it all invisible to the average programmer. The "no complex opcodes" thing was sometimes taken to extremes: There's no single-cycle algorithm for integer multiplication or division. MIPS therefore had integer multiplication and division opcodes which executed while the rest of the chip was still executing other opcodes: The code would issue a multiplication, say, and then the next n opcodes would be run while the multiplication hardware was cranking through the math; when it was done, the result would be placed in a pair of special registers, called hi and lo. How many opcodes was n? Dunno, it depended on the inputs to the multiplication opcode. Division worked the same way. I don't remember if reading hi and lo early would stall the pipeline or generate garbage... However, when you remember that the VAX had an opcode which would evaluate a polynomial of arbitrary degree when given an X value and a variable-length list of coefficients, you can kind of see where the RISC folk were coming from.
TheOtherHobbes 11y ago
Originally RISC was a combination of: Small simple instruction set, to minimise the size of the decoder Single cycle execution Aggressive pipelining Replacement of decoder space with a much larger on-chip register space The theory was everything would work faster. And this was true for a while. But eventually CISC cache killed the register speed advantage, CISC pipelining became astonishingly clever and killed the pipelining advantage, and the actual difference in efficiency between a CISC instruction decoded to u-ops and compiler translation of complex statements to RISC instructions turned out to be somewhere between not much, nothing, and negative. So RISC basically wins for relatively low performance low power computing. It's not such a win for anything that requires SIMD, MMX, or any kind of DSP extension - which today means most desktop computing. The basic problem with the premise is that it's more efficient to cache memory reads and decoded instructions and data than to keep data in registers and assume a pipeline is going to give you cache-like performance for instructions. In fact, modern CISC chips include the equivalent of a hardware compiler that tries to run an optimised internal RISC machine while also providing the benefits of fast data and u-op caching. The simple many register model is really a bit old fashioned now.
- AlphaSite 11y ago
  Well no, doesn't modern x86 have an extremely large number of registers in actuality?
  - daemonwrangler 11y ago
    Sort of. The physical register file has more registers than what's specified in the ISA in order to support out-of-order execution. Hardware maps the small number of ISA registers to the larger number of physical registers. All sorts of complex stuff happens in the hardware to make it all work out right (e.g., bypass logic between pipeline stages to make sure dependent instructions are able to use just produced data before it gets stored in the register file). All to give the hardware greater scheduling flexibility. So yes, there are more registers than you'd think by looking at the ISA, but they aren't available to the compiler, which can limit the kinds of optimizations it can make. I think when AMD introduced x86-64, they only increased ISA registers from 8 to 16. RISC ISAs at the time were offering 32-64 (and some also had larger physical register files to support OoO). Granted these days there's also all of the vector registers for SSE/AVX, but you'll need to have vectorizable code to leverage those. All that being said, I don't think cache is a replacement for the register file.

by amyjess 11y ago

cbd1984 11y ago

RISC is also often described as register-register, as opposed to register-memory or stack or accumulator-based. In a pure register-register design, all opcodes which use the ALU only operate on data stored in registers, and only store data to registers. Due to this, the only opcodes which touch RAM in such a design are load and store opcodes, and they only use the simplest addressing modes. In a register-memory design, ALU-using opcodes can touch RAM as well. This is taken to an extreme in accumulator-based designs, which aren't used much now but were previously very popular: One "main" register which is involved in all (or nearly all) opcodes, maybe a couple index registers to make memory addressing easier, and everything else is in RAM. The 6502 is the prototypical accumulator-based design, with the interesting twist that its zero page (all memory addresses with a high byte of 0x00) is almost as fast as registers, making it practically a machine with 256 one-byte registers. (Stack machines are fairly self-explanatory. I think they're mostly VMs now, because it's easy to take stack machine code, turn it back into a parse tree, and then compile that to optimized machine code.) Register-register designs are typically RISC, which implies constant-size opcodes (one machine word per) to save on decoding hardware, pipelining built in from the start (so no or few complicated opcodes which can take an unpredictable number of cycles to complete), and a very Spartan design philosophy, even to the extent of making the pipelining architecturally visible by specifying things like branch delay slots (where the opcode immediately after a taken branch opcode is still executed, because it's already in the pipeline). The idea was that the compiler would make it all invisible to the average programmer. The "no complex opcodes" thing was sometimes taken to extremes: There's no single-cycle algorithm for integer multiplication or division. MIPS therefore had integer multiplication and division opcodes which executed while the rest of the chip was still executing other opcodes: The code would issue a multiplication, say, and then the next n opcodes would be run while the multiplication hardware was cranking through the math; when it was done, the result would be placed in a pair of special registers, called hi and lo. How many opcodes was n? Dunno, it depended on the inputs to the multiplication opcode. Division worked the same way. I don't remember if reading hi and lo early would stall the pipeline or generate garbage... However, when you remember that the VAX had an opcode which would evaluate a polynomial of arbitrary degree when given an X value and a variable-length list of coefficients, you can kind of see where the RISC folk were coming from.

TheOtherHobbes 11y ago

Originally RISC was a combination of: Small simple instruction set, to minimise the size of the decoder Single cycle execution Aggressive pipelining Replacement of decoder space with a much larger on-chip register space The theory was everything would work faster. And this was true for a while. But eventually CISC cache killed the register speed advantage, CISC pipelining became astonishingly clever and killed the pipelining advantage, and the actual difference in efficiency between a CISC instruction decoded to u-ops and compiler translation of complex statements to RISC instructions turned out to be somewhere between not much, nothing, and negative. So RISC basically wins for relatively low performance low power computing. It's not such a win for anything that requires SIMD, MMX, or any kind of DSP extension - which today means most desktop computing. The basic problem with the premise is that it's more efficient to cache memory reads and decoded instructions and data than to keep data in registers and assume a pipeline is going to give you cache-like performance for instructions. In fact, modern CISC chips include the equivalent of a hardware compiler that tries to run an optimised internal RISC machine while also providing the benefits of fast data and u-op caching. The simple many register model is really a bit old fashioned now.

AlphaSite 11y ago
Well no, doesn't modern x86 have an extremely large number of registers in actuality?
- daemonwrangler 11y ago
  Sort of. The physical register file has more registers than what's specified in the ISA in order to support out-of-order execution. Hardware maps the small number of ISA registers to the larger number of physical registers. All sorts of complex stuff happens in the hardware to make it all work out right (e.g., bypass logic between pipeline stages to make sure dependent instructions are able to use just produced data before it gets stored in the register file). All to give the hardware greater scheduling flexibility. So yes, there are more registers than you'd think by looking at the ISA, but they aren't available to the compiler, which can limit the kinds of optimizations it can make. I think when AMD introduced x86-64, they only increased ISA registers from 8 to 16. RISC ISAs at the time were offering 32-64 (and some also had larger physical register files to support OoO). Granted these days there's also all of the vector registers for SSE/AVX, but you'll need to have vectorizable code to leverage those. All that being said, I don't think cache is a replacement for the register file.