I've read that the modern Intel processors use the CISC instructions on the top, which are converted into RISC-like simpler instructions in the form of Micro-Operations at the back-end.

So if Intel micro-ops are RISC-like simple hardware level controls, then what do the ARM Micro-Operations do?

Because ARM instructions are already quite RISC-like, what would their Micro-Operations form look like?

  • 3
    \$\begingroup\$ +1 This question has an easy, obvious (and correct) answer, but that doesn't make it a bad question or a candidate to be closed. \$\endgroup\$ Commented Aug 31, 2015 at 18:43
  • \$\begingroup\$ ARM has hardwired control unit. \$\endgroup\$
    – MaMba
    Commented Aug 31, 2015 at 18:54

3 Answers 3


All microprocessors, and indeed all synchronous digital circuits work in what is called a "Register Transfer Level". Basically all that any microprocessor does is loading values into registers from different sources. Those sources can be memory, other registers or the ALU (Artihmitical-Logical Unit, a calculator inside the processor). Some of the registers are simple registers inside the procesor, some registers can be special function registers that are located around the CPU, in 'peripherals' such as I/O ports, memory management unit, interrupt unit, this and that.

In this model, 'Instructions' are basic sequences of register transfers. Normally it doesn't make sense to give the programmer the ability to control each register transfer individually, because not all of the possible register transfer combinations are meaningful, so allowing the programmer to express them all would be wasteful in terms of memory consumption. So basically each processor declares a set of sets of register transfers that it allows the programmer to ask the processor to do, and these are called 'Instructions'.

For example ADD A, B, C might be an operation where the sum of registers A and B is placed into register C. Internally, that would be three register transfers: Load adder left input from A, load adder right input from B, then load C from adder output. Additionally, the processor makes the necessary transfers to load memory address register from program counter, load instruction register from memory data bus, and finally load program counter from program counter incrementer.

The 8086 used an internal ROM look-up table to see which register transfers make each instruction. The contents of that ROM were quite freely programmable by the designers of the 8086 CPU so they chose instruction sequences, which seemed useful for the programmer, instead of choosing sequences which would be simple and fast to execute by the machine. Remember, that in those days most software was written in assembly language, so it made sense to make that as easy as possible for the programmer. Later on, Intel designed 80286, in which they made, what now seems, a critical error. They had some unused microcode memory left and they thought that they might as well fill it with something, and came up with a bunch of instructions just to fill the microcode. This bit them in the end, as all those extra instructions needed to be supported by the 386, 486, Pentium and later processors, which didn't use microcode any more.

ARM is a lot newer processor design than the 8086 and the ARM people took a different design route. By then, computers were common and there were a lot of compilers available. So instead of designing an instruction set that is nice for the programmer, they chose an instruction set which is fast for the machine to execute and efficient for the compiler to generate code on. And for a while, the X86 and ARM were different in the way that they execute instructions.

Time then goes by and CPUs become more and more complex. And also microprocessors are designed using computers and not pencil and paper. Nobody uses microcode any more, all processors have a hardwired (pure logic) execution control unit. All have multiple integer calculation units and multiple data buses. All translate their incoming instructions, reschedule them and distribute them among the processing units. Even old RISC instruction sets are translated into new RISC operation sets. So the old question of RISC versus CISC doesn't really exist anymore. We're again back in the register transfer level, programmers ask CPU's to do operations and CPU's translate them into register transfers. And whether that translation is done by a microcode ROM or hardwired digital logic, really isn't that interesting any more.

  • \$\begingroup\$ "No one uses microcode any more"....I use x86 processor and I get microcode updates often. So I think that statement is false. \$\endgroup\$ Commented Jul 20, 2021 at 14:35
  • 1
    \$\begingroup\$ Shashank, yeah, well, the world has changed yet again. Nowadays there are so many different kinds of programmability (FPGA fabric etc) so the statement should be changed to "Nobody uses microcode ROM any more" which would still be at least somewhat true. But yes, reprogrammability is being introduced more and more, especially in opcode translation units. In that sense, the old days are coming back again. Someone believing in circular time should be happy... \$\endgroup\$
    – PkP
    Commented Dec 2, 2022 at 7:57

The idea that "there is a RISC inside modern x86" is quite misleading. I have the impression that it was first told by Intel as a marketing ploy when they released the i486 which was the first pipelined x86, and could execute many instructions in 1 cycle, like contemporary RISC CPUs.

The issue is that RISC and CISC is about instruction sets (which are visible to the assembly programmer), not internal microarchitecture. x86 have been designed as microcoded (8086), pipelined (80486), OoO with micro-ops (PentiumPro), VLIW (Transmeta)...

Back to the question.

The micro-operations do not really make an instruction set, they are rather similar to the signals that traverse a pipeline, selecting read and written registers, ALU operations...

Most ARM instructions can be executed in one step while many x86 instructions need to be cracked into a sequence of 2 or more micro-operations, but there is little difference.

In OoO CPUs, parts of these informations are stored in FIFOs and buffers as reservation queues, reorder buffers... These parts of instructions are certainly quite similar in principle between ARMs and x86s, but there is no "RISC inside"

  • 1
    \$\begingroup\$ The idea of the RISC inside CISC implementation started with micro-ops. I think I still have the brochure somewhere in storage. It refers to the micro-ops architecture - the CPU designers are free to design a fast RISC CPU then add a translator (Intel called it the "crack" stage) to convert the CISC instructions into equivalent set of RISC instructions for the core CPU to execute. \$\endgroup\$
    – slebetman
    Commented Sep 1, 2015 at 7:47

The ARMs don't use micro-ops!!

  • 2
    \$\begingroup\$ ARM does use micro-ops. What it does not use is microcode. A hardwired control unit does not have micro-code but that doesn't exempt the possibility of micro-ops. In ARM, Instructions are decoded into micro-ops by a hardwired control. \$\endgroup\$
    – Kraken
    Commented Aug 31, 2015 at 21:00
  • \$\begingroup\$ @Kraken: While the possibility is there, I highly doubt that any ARM variant uses micro-ops. That's because each ARM instruction is already a micro-op. What some ARM chips have instead are the opposite of micro-ops - thumb instructions are EXPANDED into an equivalent ordinary instruction. Instruction decoding into signals are just that: decoding. By that stage it's no longer an "op" - they're just signals. Some CPUs do latch the decoded signals into an intermediate register (the Soviet Elbrus for example) but that decoded signal looks more like a VLIW instruction rather than a micro-op. \$\endgroup\$
    – slebetman
    Commented Sep 1, 2015 at 7:43
  • 1
    \$\begingroup\$ @slebetman That makes sense, of course. But a while ago I was reading this document about a cortex processor which has micro-ops for complex functionalities. That is why I asked this question. May be they are using the term to refer to something else... \$\endgroup\$
    – Kraken
    Commented Sep 1, 2015 at 11:27
  • 1
    \$\begingroup\$ @Kraken: In cases like that it's actually micro-ops. Sorry I wasn't aware of that. What happens is that some functionalities like square root aren't implemented in hardware directly to save space. The instructions instead trigger traps/interrupts. From there there are two choices that the designer has: either insert a series of instructions that will calculate the desired result into the instruction stream (micro-ops) or just document the trap and let OS programmers/compiler writers implement the feature in software (emulation). \$\endgroup\$
    – slebetman
    Commented Sep 2, 2015 at 3:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.