Comment by gary_0
1 year ago
That's not exactly it; quite a few RISC-style instructions require multiple (sometimes many) clock cycles to complete, such as mul/div, floating point math, and branching instructions can often take more than one clock cycle as well, and then once you throw in pipelining, caches, MMUs, atomics... "one clock cycle" doesn't really mean a lot. Especially since more advanced CPUs will ideally retire multiple instructions per clock.
Sure, addition and moving bits between registers takes one clock cycle, but those kinds of instructions take one clock cycle on CISC as well. And very tiny RISC microcontrollers can take more than one cycle for adds and shifts if you're really stingy with the silicon.
(Memory operations will of course take multiple cycles too, but that's not the CPU's fault.)
>quite a few RISC-style instructions require multiple (sometimes many) clock cycles to complete, such as mul/div, floating point math
Which seems like stuff you want support for, but this is seemingly arguing against?
It seems contradictory because the "one clock per instruction" is mostly a misconception, at least with respect to anything even remotely modern.
https://retrocomputing.stackexchange.com/a/14509
Got it, so it's more about removing microcode.
The biggest divide is that no more than a single exception can occur in a RISC instruction, but you can have an indefinite number of page faults in something like an x86 rep mov.
That's not even true as you can get lots of exceptions for the same instruction. For example a load can all of these and more (but only one will be reported at a time): instruction fetch page fault, load misaligned, and load page fault.
More characteristic are assumptions about side effects (none for integer, and cumulative flags for FP) and number of register file ports needed.