18 ms·

Is there even any point of referring to an ISA as distinctly 'RISC' or 'CISC' anymore? Modern AMD64 'CISC' (and even some ARM machines, despite being considered

Is there even any point of referring to an ISA as distinctly 'RISC' or 'CISC' anymore? Modern AMD64 'CISC' (and even some ARM machines, despite being considered 'RISC') machines are held together behind the scenes by a microcode with a much smaller arsenal of instructions, and then you have stuff like this where a RISC-V ISA chip might fuse ops together in a very CISC-like abstraction.

_chris_ 10y ago
> Is there even any point of referring to an ISA as distinctly 'RISC' or 'CISC' anymore? First, you need to be careful to not confuse the ISA with the micro-architecture. RISC and CISC are descriptions of the interface that the SW sees, and the fact that Intel processor pipelines use RISC-like micro-ops doesn't change the fact that the x86 ISA is very CISC-y (just look at the picture of all the x86 registers). Of course, the fact that we can so readily decouple the ISA from the implementation does help us lessen the sins committed in bad ISA designs, which is where are RISC arguments come back in to play - if we can make all ISAs execute at about the same performance, why not go with the simplest ISA to implement? Of course, although I'm being provocative in the report, in reality, RISC and CISC are not binary terms - they're points on a continuum. For example, RISC-V's RV64I (integer-only) is incredibly RISC-y (not even a multiply!), but once you add in double-precision FMAs ("D") and atomic memory operations ("A") and variable-length instructions ("C")... well, it's not CISC like VAX, but it's certainly not pure RISC!
- Taniwha 10y ago
  The thing is the base x86 architecture ISNT very CISCy, there's only simple addressing modes (no double indirect modes), no addressing side effects to undo on exceptions (auto increments), only one TLB dip per instruction (the push instruction is really the only excepetion) compared to its compatriots (68k/vax/NSwhatever etc) it was positively RISCy in comparison - a vax instruction could take something like 29 TLB misses, make 29 memory accesses - a 68020 threw a horrible mess of microstate spew on a TLB miss so it could make progress (made unix signals implementation a nightmare, where do you safely put that stuff?) I think its RISCyness is why it's still with us

_chris_ 10y ago

> Is there even any point of referring to an ISA as distinctly 'RISC' or 'CISC' anymore? First, you need to be careful to not confuse the ISA with the micro-architecture. RISC and CISC are descriptions of the interface that the SW sees, and the fact that Intel processor pipelines use RISC-like micro-ops doesn't change the fact that the x86 ISA is very CISC-y (just look at the picture of all the x86 registers). Of course, the fact that we can so readily decouple the ISA from the implementation does help us lessen the sins committed in bad ISA designs, which is where are RISC arguments come back in to play - if we can make all ISAs execute at about the same performance, why not go with the simplest ISA to implement? Of course, although I'm being provocative in the report, in reality, RISC and CISC are not binary terms - they're points on a continuum. For example, RISC-V's RV64I (integer-only) is incredibly RISC-y (not even a multiply!), but once you add in double-precision FMAs ("D") and atomic memory operations ("A") and variable-length instructions ("C")... well, it's not CISC like VAX, but it's certainly not pure RISC!

Taniwha 10y ago
The thing is the base x86 architecture ISNT very CISCy, there's only simple addressing modes (no double indirect modes), no addressing side effects to undo on exceptions (auto increments), only one TLB dip per instruction (the push instruction is really the only excepetion) compared to its compatriots (68k/vax/NSwhatever etc) it was positively RISCy in comparison - a vax instruction could take something like 29 TLB misses, make 29 memory accesses - a 68020 threw a horrible mess of microstate spew on a TLB miss so it could make progress (made unix signals implementation a nightmare, where do you safely put that stuff?) I think its RISCyness is why it's still with us