3 ms·

No, although one could make that argument. RISC (reduced instruction set) has a few characteristics besides just the number of instructions -- most "working" in

by addaon 5y ago

No, although one could make that argument. RISC (reduced instruction set) has a few characteristics besides just the number of instructions -- most "working" instructions are register-to-register, with load/store instructions being the main memory-touching instructions; instructions are of a fixed size with a handful of simple encodings; instructions tend to be of low and similar latency. CISC starts at the other side -- memory-to-register and memory-to-register "working" instructions, variable length encodings, instructions of arbitrary latency, etc. FISC ("fast instruction set") was a term used for POWER/PowerPC to describe a philosophy that started very much with the RISC world, but considered the actual number of instructions to /not/ be a priority. Instructions were freely added when one instruction would take the place of several others, allowing higher code density and performance while staying more-or-less in line with the "core" RISC principles. None of the RISC principles are widely held by ARM today -- this thread is an example of non-trivial memory operations, Thumb adds many additional instruction encodings of variable length, load/store multiple already had pretty arbitrary latency (not to mention things like division)... but ARM still feels more RISC-like than CISC-like. In my mind, the fundamental reason for this is that ARM feels like it's intended to be the target of a compiler, not the target of a programmer writing assembly code. And, of the many ways we've described instruction sets, in my mind FISC is the best fit for this philosophy.

microtherion 5y ago
> RISC (reduced instruction set) has a few characteristics besides just the number of instructions Many (or all?) of the RISC pioneers have claimed that RISC was never about keeping the number of instructions low, but about the complexity of those instructions (uniform encoding, register-to-register operations, etc, as you list). "Not a `reduced instruction set' but a `set of reduced instructions'" was the phrase I recall.
- monocasa 5y ago
  It's both. Most of RISC falls out of the ability to assume the presence of dedicated I caches. Once you have a pseudo Harvard arch and your I fetches don't fight with your D fetches for bandwidth in inner loops, most of the benefit of microcode is gone, and a simpler ISA that looks like vertical microcode makes a lot more sense. Why have a single instruction that can crank away for hundreds of cycles computing a polynomial like VAX did if you can just write it yourself with the same perf?
Gaelan 5y ago
> Thumb adds many additional instruction encodings of variable length, load/store multiple already had pretty arbitrary latency Worth noting that, AFAIK, both of these were removed on aarch64 (and aarch64-only cores do exist, notably Amazon's Graviton2)

by addaon 5y ago

microtherion 5y ago

> RISC (reduced instruction set) has a few characteristics besides just the number of instructions Many (or all?) of the RISC pioneers have claimed that RISC was never about keeping the number of instructions low, but about the complexity of those instructions (uniform encoding, register-to-register operations, etc, as you list). "Not a `reduced instruction set' but a `set of reduced instructions'" was the phrase I recall.

monocasa 5y ago
It's both. Most of RISC falls out of the ability to assume the presence of dedicated I caches. Once you have a pseudo Harvard arch and your I fetches don't fight with your D fetches for bandwidth in inner loops, most of the benefit of microcode is gone, and a simpler ISA that looks like vertical microcode makes a lot more sense. Why have a single instruction that can crank away for hundreds of cycles computing a polynomial like VAX did if you can just write it yourself with the same perf?

Gaelan 5y ago

> Thumb adds many additional instruction encodings of variable length, load/store multiple already had pretty arbitrary latency Worth noting that, AFAIK, both of these were removed on aarch64 (and aarch64-only cores do exist, notably Amazon's Graviton2)