ARM vs RISC and x86 vs CISC

Question

By doing some researches I realized that ARM and RISC are used pretty much interchangably and the same goes for x86 and CISC. I understand that RISC and CISC are the architectures. My understanding is that the architecture (i.e. RISC or CISC) is kind of a set of instructions that the process has to be able to do in order to be one of those architectures. For example RISC-V has a list of instruction it can do and CISC has a list of instruction it can do. To be RISC or CISC a processor has to be able to execute one of the particular list of instruction. However, I don't understand then what is the difference between ARM and RISC and x86 and CISC respectively. Are ARM and x86 not the architectures as well? Often I read, "ARM architecture" or "x86 architecture". Thank you for clarifying this for me.

Answer 1

ARM and RISC are used pretty much interchangably - Nope, RISC is a category that includes ISAs like ARM, PowerPC, MIPS, RISC-V, SPARC, 8-bit AVR, and others.

ARM is one of the least RISCy, having a load-multiple instruction and complex addressing modes. But it has RISC attributes like a fixed-width machine-code format (except in Thumb mode). And being a load/store machine (ALU instructions can't have memory operands).

Same for CISC being a category of which x86 is the most prominent current member. Others include Motorola m68k, and current microcontrollers like MSP430. Vax is a notable historical machine which famously has large possible complexity in a single instruction, like instructions can have both operands be memory, not registers, both with complex addressing modes, so the max instruction length is large.

My understanding is that the architecture (i.e. RISC or CISC) is kind of a set of instructions that the process has to be able to do in order to be one of those architectures.

No. There's no instruction-list for RISC in general or CISC in general.

One of the general features of a CISC ISA is that it will include an instruction like add reg, [memory] and usually add [memory], reg, not just add reg, reg.

Almost all architectures include an add instruction, so it's not interesting for a machine to have an instruction with that name. Many ISAs of either type have some kind of multiply instruction, and with CISCs it usually allows a memory source operand.

You could say that having push and pop instructions is quite common among CISCs, and rare among RISCs. (ARM has it, most others don't, although in ARM (not Thumb) mode it's just a special case of load-multiple / store-multiple which takes a bitmap of which registers to operate on. ARM's push/pop is more CISCy than the one-register push/pop instructions on typical CISCs).

RISC ISAs are more likely to be 3-operand (add dst, src1, src2) instead of add dst, src2 doing dst+=src, but AVR is a counterexample: it's an 8-bit RISC with 2-byte instruction words, so it doesn't have room for 3 register numbers per instruction.

CISCs often use a variable-length machine-code format, so some instructions are only 1 byte, others can be longer (e.g. x86 limits the max instruction length to 15 bytes). Having variable-length instructions would mostly rule out an ISA from being RISC, except for a "compressed" instruction format like ARM Thumb or RV32C for RISC-V, where there are 2 fixed sizes of 16 or 32 bytes, and it's still easy to find instruction boundaries because the instruction format was designed to make decoding efficient. (Including parallel decoding.)

---

But anyway, there isn't some list of instructions you can use to write a "RISC program" that can assemble for any RISC ISA. There are too many differences between different RISC architectures for anything like that to be plausible. Same for CISC.

---

This will all become a lot more obvious if you learn a bit of assembly language, or for example look at compiler output for x86 vs. for RISC-V. (Or if you want a headache trying to decipher the meaning of the mnemonics, PowerPC. :P)

How to remove "noise" from GCC/clang assembly output? - especially the link to Matt Godbolt's talk.

Answer 2

I understand that RISC and CISC are the architectures.

They aren't; RISC and CISC are design philosophies. Specifically; the RISC philosophy is/was the idea that a simpler CPU can be run at a higher frequency and be faster (in addition to being cheaper and easier to design).

Originally this was mostly true (especially if you're willing to be deceived by "twice as many instructions per second (with twice as many instructions needed to get the same amount of work done)").

Then (late 1990s) chips hit frequency limits caused by physics/semi-conductor manufacturing, and complexity increased for other reasons (super-scalar/out-of-order, SIMD support, etc); nullifying any benefits of RISC.

In response to this; RISC advocates started redefining what RISC is in an attempt to hide the fact that the RISC philosophy is fundamentally flawed. Some decided that RISC just means "load/store architecture" (and some decided it meant "no micro-code", and others decided it meant "fixed length instructions", and ... - there's is no consensus); but in all cases they're trying to imply that it doesn't matter that modern "RISC" designs are as complex as CISC in every way (including the number of instructions in the instruction set).

The other thing that happened is that 80x86 grew in a backward compatible way; with "extension on top of extension on top of extension" leading to various problems (e.g. a variety of different prefixes as way to increase the opcode space, reducing code footprint, reducing the effectiveness of instruction caches, increasing the complexity of decoding, etc); and people compare 80x86 to modern 64-bit ARM and think it's a fair "CISC vs. RISC" comparison when it's actually a "old CISC with 40+ years of baggage vs. new equally complex ISA with a lot less baggage" comparison.

Answer 3

ARM, MIPS, etc are all RISC in fact most folks (that went through university, for some large window of time) think RISC=MIPS. But it is MIPS=RISC as well as ARM=RISC.

CISC just means the instructions are more complicated and RISC they are less complicated. From a textbook-ish view. The reality today is while your x86s are still going to be microcoded (as with other CISC) the line between RISC and CISC is a bit blurry, CISC uses pipelines, both can have deep pipelines, can hide the differences between them.

You go back to the early days it made a huge amount of sense, and would have loved to have been a fly on the wall when these things were going on, but. To microcode these processors, your chips were literally hand drawn masks, huge potential for error, every extra transistor/connection you made, you added to the risk of failure at huge cost (well I wonder if today's costs are higher in adjusted for time pricing).

So designing a relatively simple state machine, think VLIW, having 8 bit "opcodes"/"instructions" that basically were used to look up the actual instructions in a programmable ROM buried in the device. Allowed for a small memory footprint for the programs, and each instruction could do complicated things. Addition with one or more of the operands or result being a memory location, is a complicated instruction, it takes many steps. Then you can change your mind later as to how much microcode per instruction it takes to implement that instruction, like today with the x86 and the occasional microcode updates we see, you can change your mind after the silicon is produced.

RISC comes along as advertised for performance, it came with features that helped greatly but some everyone uses today, but instead of an add with memory operands or a result turn that into multiple instructions load into a register or two, do the addition only using registers then if the result wants to go back to memory then store it. Memory by this point is now dynamic not static and much cheaper, relatively, so wasting extra program space for the return on performance, great. Throw in a pipeline, throw in fixed length instructions, throw in aligned only loads and stores, and you reduce the complexity of the processor and improve the performance over a CISC design, at the time that this was happening.

You could obviously not microcode CISC and you could microcode RISC, but one leans one way and one leans the other. Everyone uses a pipeline now, and I argue because of lazy x86 programmers the RISC folks are adding the complexity to do unaligned accesses, and of course you have a performance penalty (you don't see it in x86 necessarily because of the serious amount of logic overhead built into the design, primarily to have reverse compatibility of the original instruction set and its evolution).

Neither CISC nor RISC mean reverse compatibility but certainly for the CISC poster child of x86, it has affected its overall design and you can make a cleaner and leaner CISC, if not even cleaner and leaner than a RISC from an overall amount of logic perspective not counting the control store.

The differences have largely been erased, some of the early players when it might have been more noticeable are still here and have some level of reverse compatibility which muddies the water for their specific implementations.

CISC and RISC are not architectures they are closer to concepts. Maybe like all wheel drive vehicle vs two wheel drive and front wheel drive vs rear wheel drive. A lot of the car is the same for each concept, but there are certain design elements that you build for that type, you don't necessarily make a front wheel drive with a transmission under the passengers with a drive shaft going all the way back then reflect back to the front, you build that different. But all wheel drive you have some choices as to how to drive the wheels...

For historical reasons ARM, MIPS, RISCV are considered RISC. x86, 6502, and many others are considered CISC.

RISC is not necessarily load store, it leans that way to reduce the complexity but you see the popularly named RISC processors have exceptions.

So what are the "differences", with your CISC 6502, z80 (very much in use today incidentally, dozens of z80s are used to get this web content between you and me), x86, etc. You have an 8 bit opcode/instruction. With some tiny bit of encoding but for the most part the instruction bits do not indicate what the instruction does you do not have a list of the registers used and the opcode buried in this instruction. This instruction is just a bit pattern that you look up in a table to see what it does. And when implemented that leans toward microcoding which is basically states in a state machine if you will that perform all the steps.

RISC implementations have been more of a solution where the instruction itself has bits that indicate the operation, and operands, everything you need to know is right there, so the processor can just go do those things.

As mentioned CISC will tend to have memory operands for things like add and not just for load/stores. Where RISC will tend to not have memory operands except only for load/store instructions.

But IMO this is just how these evolved as implementations. You could make a RISC with 8 bit instructions and have state machines (with or without microcoding, your choice) that execute that instruction. And you could have CISC with opcode and operands visible in the encoding of the instruction, with alignment rules on the loads and stores, etc.

But.....these are terms like Harvard and von Neumann, and embedded and bare-metal and others in the processor world that are largely defined by the company or individual. In a lot of cases, marketing departments. You will often see the marketing state our product is a this with a that using these kinds of terms. Ideally trying to catch the eye of particular markets. Yet you can easily find conflicts in the textbook-ish definitions (assume no two textbooks are going to agree either). So we have to do things like x86 is CISC and MIPS is RISC and what are the early/classic as well as current differences between them. It is like thinking that what GCC does with the C language is thought to be THE C language, where instead that is one implementation, and not the definition of the language.

And I would argue that RISC is if you will a largely marketing type attack on the CISC of the day (and I assume the RISC folks made the name CISC, but I do not know). We have this new invention and we think it is "better" than yours, because we did this, we reduced the complication for performance reasons, and here is our "implementation". Can you separate the "concept" vs the early/current "implementations"?

Answer 4

I know I am late to the party, but... "Reduced" and "Complex" are very relative concepts : complex/reduced compared to what, exactly? Since ISA's have largely been engineered for the most part in shrouded secrecy until release, and have sometimes evolved in completely segregated environments (if you have time, search Youtoob for videos on the semiconductor industry in East Germany and the USSR during the Cold War : you'll notice some striking differences indesign choices), there never really was any one implementation designated 'ex post facto' as THE benchmark against which everything else is to be measured. So, in practice it is largely left to the appreciation of the user/buyer/observer/OEM to judge which architecture is which. Historically, the RISC concept emerged at the Uni of Berkeley (Calif) in the late 70's IIRC, and was just a concept that ended up being put in the Public Domain, thus leaving any OEM who so desired to build on it (much like the much more recent RISC-V) with any additions they deemed useful (for better or worse).

It gets worse : since the 90's and the proliferation of different RISC ISA's implemented since the concept's emergence, RISC CPUs have seen such a huge number of (often proprietary) additions to their instruction sets -each one to fit a specific purpose or use case, much like a CISC set- that most of them ended up featuring such a total number of different instructions that the line with the CISC world got increasingly blurry. So much so that in the last decade, I've noticed an increasing use of the replacement term "MISC" (which stands for "minimal instruction set computer"), supposed to designate an ISA that most closely adheres to the original RISC philosophy in its sparsity and small number of instructions.

Then again, an interesting and recent approach is the RISC-V I've mentioned before, which implements a modular kind of ISA : a basic set, upon which an OEM can then graft some modules (either pre-engineered by the consortium offering the concept -for free- or customized "à la ARM") that come and extend this base with more specific features. I recommend checking the Wikipedia page, it's pretty interesting and I'd be willing to wager than in a few years it'll become a serious thorn in the side of ARM Holdings Ltd. in the mobile SoC market, for it sure is a very elegant solution indeed. :)