3 ms·
I think it's useful to draw a distinction between instructions that are somewhat complex versus overall design choices that make decoding (and scheduling) hard.
by dgacmu 3y ago
I think it's useful to draw a distinction between instructions that are somewhat complex versus overall design choices that make decoding (and scheduling) hard. Like, does it really matter if you have a reciprocal square root instruction? Or is it more important to have fixed length instructions with an easy decode path? And a way to avoid a lot of implicit dependencies on, e.g., status flags? RISC got many of these things right, but it wasn't really by avoiding complex instructions.
(The fact that arm has a reciprocal square root instruction gives away my opinion a little bit...)
Dark silicon and power limits changed the equation a lot, as you observe.
- gpderetta 3y ago> does it really matter if you have a reciprocal square root instruction it was important at the time of the original RISC as anything that could not be handled by the single-cycle execution stage would significantly increase the complexity of the pipeline. Today pipelines are orders of magnitude more complex than the original RISC, so it doesn't really matter.
- librasteve 3y agoi dont think so ... without reciprocal square root, you would need to issue a square root and a reciprocal instruction sequentially and trust your compiler to unroll, pipeline ir whatever. anyway, square root on an IEEE P754 FPU is going to use something like microcoded newton-raphson with a variable number of cycles to reach sufficient accuracy. BUT, the result of the two chained instructions will often be different to that of the unified instruction (like mac is different to multiply then add) so this MAY be a philsophical decision, or more likely someone could code LINPACK tighter