processors
ARM is CISC
ARM stands for Advanced RISC Machine. In its press releases, ARM refers to its processor architecture as a RISC architecture. And this is seen as a good thing — something to differentiate it from the awful mess that is Intel’s ISA, and the even more convoluted x86-64 extension to it.
But its instruction set has been getting more and more complicated. Granted, it’s not in the ugly, pointless way that IA32 is complicated; each of the design decisions seem quite sensible, and there’s no overall problems with the new features taken together. But while I was reading about the IT instruction in Thumb2, I was suddenly reminded of the SKIP instructions from foregone days of yore, and realized they’d resurrected that ancient ISA mainstay — and had excellent arguments why it was useful! The ARM engineers aren’t idealists.
So according to Wikipedia, RISC architectures normally exhibit the following features:
- Uniform instruction format, using a single word with the opcode in the same bit positions in every instruction, demanding less decoding. As of Thumb2, you can mix 16-bit and 32-bit instructions.
- Identical general purpose registers, allowing any register to be used in any context, simplifying compiler design (although normally there are separate floating point registers). Except for now, only the first 8 registers have easy access in Thumb mode, the higher registers requiring different instructions to access them. Furthermore, the PUSH and POP instructions only work on the stack pointer, and the call instructions only work on the dedicated link register, which, not being one of those first 8, are hard to access for other things. ARM has just about the same number of truly general-purpose registers as Intel.
- Simple addressing modes. Complex addressing performed via sequences of arithmetic and/or load-store operations. Due to LDM and STM and pre- and post-decrement, I would argue this was never true to begin with.
- Few data types in hardware, some CISCs have byte string instructions, or support complex numbers; this is so far unlikely to be found on a RISC. Eh.
With the introduction of bounds-checking in ThumbEE, I am reminded of the IA32 BOUND instruction, one I often saw cited as an instruction that made it abundantly clear that IA32 was very much so CISC. In the section “Non-RISC design philosophy” on the Wikipedia article, it says:
With the advent of higher level languages, computer architects also started to create dedicated instructions to directly implement certain central mechanisms of such languages.
Bounds checking fits that, and thus it is a very CISC-y thing to do, indeed.
So what can we make of this? If this were a liberal arts paper, I would have said that I’ve proven my thesis, even though I’ve given no practical application of this knowledge or reason why anyone should care. I guess my point is that things shouldn’t be designed on ideology. ARM is a great architecture; it manages to maintain many of the advantages of RISC. Its ability to save power is extremely impressive, its decoding is much simpler than Intel’s, it is in general a very well-designed architecture. And they did this without maintaining the religious adherence to RISC principles that seems to have been the basis for the MIPS architecture. They focus on the facts and on the data, and their decisions have an empirical basis.
And that’s how all engineers should work. Aesthetic of ideas is all well and good, but the facts should back it up, and concepts should compete on their merit, not their coolness. RISC has made its contribution to processor design, and the lessons learned from the RISC v. CISC war are rather important — IA32 has so many issues it’s not even funny. But, in the end, I think a pragmatic CISC wins the day, and the lessons from it can be carried over to other branches of engineering.