Classic RISC CPUs like ARM and MIPS basically offer the trade-off: simple instruction set, but instructions execute in one cycle for good overall performance. (It gets more complicated in later times, but I'm talking about seventies and eighties technology.)

But e.g. the 6502 is in many ways quite simple, yet takes a minimum of two cycles per instruction. I'm guessing that could have been one cycle for the simplest instructions, but only by making the chip bigger, and low cost was the primary objective.

Which leads me to conjecture that a simple instruction set doesn't automatically get you one instruction per cycle; maybe the classic RISC CPUs took the transistors saved on complex instructions, and spent them instead on things like full-width ALUs and extra pipeline stages, or whatever ways there are to make a CPU run faster, and that's why they execute many instructions in one cycle.

Which would seem to leave a niche for a RISC CPU that has a simple instruction set, fixed format and load/store, that executes most instructions in two cycles and is extremely cheap. If such existed, that would seem to be evidence for my conjecture; if not, then maybe I am misunderstanding the trade-offs.

So did any such CPU ever exist?

  • 3
    That question is a bit unclear. Do you ask if there are RISC CPUs (by whatever definition) that had (some) instructions with more than one cycle, or do all have to have more than one (Ignoring the question what kind of cycle)? Also, consider that the 6502 in fact does two cycles per clock cycle. As of now the question doesn't make much sense, as it tries to imply connections that are not there.
    – Raffzahn
    Commented Jan 26, 2020 at 10:47
  • 1
    @Raffzahn look for example at the CLC instruction on the 6502. It takes two clock cycles. There is no fundamental reason why it should take more than one. I conjecture that the reason it takes two, is to save chip area. Is this not so?
    – rwallace
    Commented Jan 26, 2020 at 11:17
  • 3
    Which 2 byte operations that take 3 cycles can be done in two instead? I'd know of none. All two byte immediate take 2 cycles. The ones taking 3 are ZP addressing, which need the third cycle to access the ZP location, don't they? Only single byte, non memory access instructions take a second cycle that could be saved. Namely all flag instructions and IN*/DE* and T**. And for the chip area argument you're assuming that it is mandatory to always archive a maximum and it needs a strong reason not to do so. In real life it's about being good enoug, not spending more time in optimizing a minor case
    – Raffzahn
    Commented Jan 26, 2020 at 12:10
  • 4
    For MIPS (early MIPS at least - all I had experience with), part of what gets you "one instruction per cycle" is the exposure to the programmer of load delay (it takes an extra cycle to read the source operand) and branch delay (it takes an extra cycle to fetch the destination instruction). In other words, the instructions actually take 2 cycles to complete the function they are there for, but the program can be doing something else in the meantime.
    – dave
    Commented Jan 26, 2020 at 13:25
  • 4
    I think there's a big difference between executing an instruction in one cycle and producing an instruction result on every cycle through pipelining. The latter is what the designs are trying to achieve.
    – Brian H
    Commented Jan 26, 2020 at 13:57

6 Answers 6


Classic RISC CPUs like ARM ... instructions execute in one cycle ...

This assumption is not correct.

The ARM-2 CPU (VL86C010, one of the first ARM CPUs) took:

  • Only one cycle for most operations (as you expected it)
  • Typically two cycles if a jump/branch was done
  • Up to 4 cycles for shift/rotate operations
  • Up to 16 cycles for multiply operations
  • Up to 17 (or even 18?) cycles for an LDM instruction

... and each "cycle" took two oscillator clock cycles.

This is still true on modern ARM processors. Even the real-time focused Cortex-M cores need (at least) 2 cycles for memory accesses and up to 12 cycles for divisions (e.g. for the Cortex-M3). This is even more true on the larger application processors, where deeper pipelines, out-of-order execution, complex SIMD instructions (not very RISC-y anyways), caches and concurrent accesses by multiple cores and DMA make execution times less predictable (e.g. Cortex-A8).

  • 1
    Shifts/Rotates took 0 or 1 additional cycle because ARM did not have an explicit shift/rotate instruction. It was always part of another instruction such as MOV or ADD. eg. ADD of 2 registers with a shift on the second operand by a constant was 1 cycle. An ADD of two registers with a shift on the second operand contained in a third register took 2 cycles. Also, where did you see that a cycle took two oscillator clock cycles? From the data sheet, I see that the processor takes two clock signals of the same frequency to drive the chip
    – Nam San
    Commented Jan 27, 2020 at 23:42
  • 1
    @NamSan The timings are taken from the "Acorn RISC Machine family data manual" by "VLSI Technology, Inc.". The table on page 2-11 says that operations with shifts (e.g. ADD R1, R2, R3, SHR R4) take one cycle more than the same instruction without shift (e.g. ADD R1, R2, R2). Commented Jan 28, 2020 at 6:01
  • 1
    Sounds like we agree that a shift can take an extra cycle if it’s not an immediate constant. But how did you arrive at 4 cycles in your answer?
    – Nam San
    Commented Jan 28, 2020 at 12:21
  • 2
    @NamSan The 4 cycles are - as far as I understood correctly - the maximum for an instruction that performs a shift and writes the result to the PC register. Commented Jan 28, 2020 at 18:21
  • 1
    @NamSan: Adding a shifted value to a PC may sound obscure, or using a RAM address formed with a right-shifted index may sound obscure, and not all ARM variants support such things, but I've used that construct useful when jumping to a function based on the top four bits of a halfword. Use a jump table populated with sixteen 8-bit values, jumping to functions that all fit within one Kbyte of code space.
    – supercat
    Commented Apr 30, 2020 at 21:41

To start with, cycles, especially cycles in term of some external clock source aren't really a good measurement at all. Already with the mentioned 6502 internal workings are tied to two clocks effectively doubling the clock rate the chip works at (PHI0->PHI1/2). Something easy to see with the Visual 6502 simulator.

Next, as Martin Rosenau has shown, even RISC CPUs take multiple cycles when either needing to fetch additional words (like addresses) , or needing multiple cycles to perform complex tasks (like shifting).

It seams as if the question comes rather down to why the 6500 designers didn't optimize single-byte, non-memory-accessing instructions down to one cycle and an assumed reasoning that this would be to save an substantial amount of chip real estate (transistors).

The Answer here is a clear maybe.

Then again, the 6500 design wasn't an academic work of love to create the best possible implementation, but rather about bringing a cheap CPU to market. Here investment for design time as well as time to market is at least as important than chip optimization, if not more.

They had a single and perfect working mechanic that did benefit all instructions, resulting in a minimum execution time of 2 clocks and making all instructions working with out wasting cycles - except for flag manipulation, register transfers and increment/decrement, which needed a second cycle due the way instruction handling was set up. They (except for the last) could have been made to execute in a single cycle. Saving that may have needed a few additional transistors, but more important, it would have needed additional design time - a costly up front resource - and, as well slowed time to market, a crucial point in every project, especially in the heated competition back then.

Beside and maybe even more relevant: The additional cycle has to be recognized as something relevant at all. A step often ignored when looking at something in hindsight. To solve an issue, it has to be seen as such in the first place.

So I'd say, if seen as an issue at all, it was taken as a negliable side effect, nothing to spend much time on.

P.S.: The 65C02, BTW, did show with the single cycle NOPs, that it isn't big deal to get execution down to a single cycle. All while keeping the same basic structure.

  • 4
    A very interesting device from Harris was the RTX2000 (designed to directly implement Forth!) - I went to the seminar at Harris at the time. It advertised a 'zero overhead return (because the return stack was popped at the same time as the parameter stack which contained the result of the operation). Further reading soton.mpeforth.com/flag/jfar/vol6/no1/article1.pdf Commented Jan 26, 2020 at 16:58

Classic RISC CPUs like ARM and MIPS basically offer the trade-off: simple instruction set, but instructions execute in one cycle for good overall performance

This is a misconception based on an oversimplification of the actual reasons for the RISC architecture. The real difference between RISC and CISC instructions is about using fixed, special purpose hardware to implement instructions, rather than more general hardware that is controlled by microcode. The reason this is beneficial is that by doing this, you can ensure that the parts of the processor used by each instruction follow a clear, logical progression, which allows you to overlap instructions. The downside is that doimg this for complex instructions would require a lot of hardware, so tokeep the processor size manageable you need to keep the instructions simple.

The one-cycle-per-instruction thing then comes from the fact that, in ideal circumstances, you can start one instruction per cycle and finish one per cycle. But in reality, for typical 70s/80s designs, instructions actually took about 5-6 cycles to execute, growing to ever larger numbers ofcycles as clock rates increased later on. I don't think any real RISC cpu ever took only 2 cycles per instruction... although, now I think about it, this toy design I worked on a couple of years ago did. In this example, every instruction takes two cycles to execute, but because thereare two pipeline stages there are usually two instructions executing at a time, resulting in 1 instruction per cycle ... except in a handful of cases (conditional execution may cancel the following instruction, but the first stage of it still executes, resulting in a pipeline bubble, and jumps cause another single cycle bubble). Real processors are more complex but the same basic principles apply: execution ideally manages one instruction per cycle, but some instructions or conditions may cause either bubbles (where a single cycle doesn't have an instruction completing) or stalls (where all the instructions in the pipeline fail to move to the next stage).

Not dispatching new instructions every cycle doesn't gain much. You may avoid some pipeline hazards by doing so, thus reducing the number of bubbles or stalls, but it's not likely to do much to improve the cycle rate, and would certainly decrease throughput, so it would generally not be a good strategy. Some multithreaded CPUs do something similar by switching between multiple threads on a per clock basis -- this avoids the hazards in the same way, but does not decrease utilization (at least as long as there are enough running threads to keep all the slots full). This idea was historically similar to the "barrel processor" of some early very-high-capacity computers. I believe the IO processors of the CDC 6000 (designed by Seymour Cray) may have been the original example of this idea. Other significant examples include the UltraSPARC T1, which has2 threads per execution core.

  • 2
    Is use of microcode then one of the identifying properties of being a CISC processor? Commented May 1, 2020 at 1:33
  • 3
    @hippietrail It's certainly suggestive. There are, as always, exceptions: I understand some ARM processors have microcode for some instructions, for example. But this happens within a pipeline stage and causes a stall while the microcode runs, IIRC.
    – occipita
    Commented May 1, 2020 at 7:41
  • The earliest RISC designs had interesting "features" like always executing the instruction after a branch, whether taken or not. I suppose the simplest way in terms of logic to resolve a pipeline hazard is to not even bother and just plow on through.
    – RETRAC
    Commented Nov 23, 2021 at 13:58

One RISC CPU I know of is included in the PIC microcontrollers:

I happen to have an old General Intruments data book that says the oscillator clock is divided by sixteen for some part, and by four for some other part.

The well-known 8-bit PICs by Microchip divide their system clock by four into instruction cycles.

However, there were clones that run at one instruction cycle per (oscillator) clock cycle, Parallax SX.

  • 1
    I wouldn't name PIC 8bit microcontrollers a RISC CPU. They are clearly not, except in marketologistic slogans. They can modify a value in the internal memory (that is called, again, "registers" in their documentation) in a single instruction. This is clearly not a RISC approach.
    – lvd
    Commented Jan 27, 2020 at 15:59
  • 1
    Well, that's just one attribute not met. GI didn't call it RISC, Microchip does, so it might be marketing language, as many other buzzwords, too. However, I think that the CPU in the PICs complies with some common attributes of RISC, mainly the reduced instruction set. Do you have a standardized definition, and a list which CPUs comply to all traits? I wonder if most architectures advertised as RISC are in this list. Commented Jan 27, 2020 at 17:08
  • 2
    That simply means that "RISC" should not be understood literally. We can count all possible instructions in a 32bit ARM codeword -- will that count be anyhow "reduced"? To me, "RISC" is more about a load-store architecture, where all calculations are performed in registers, where there are 16 or more general-purpose registers, where instructions have fixed length, where there is a strong tendency to carry out every instruction in a single cycle in a pipeline. Anyway this is also an opinion-based understanding of the "RISC" word, however not as wide as simply "reduced instruction set".
    – lvd
    Commented Jan 27, 2020 at 17:53
  • 2
    All calculations are performed in registers - check (even though not symmetrically). -- 16 or more general-purpose registers - check. -- instructions have fixed length - check. -- every instruction in a single cycle in a pipeline - check. :-D However, the core does not have any RAM by this interpretation. Does it have to have that? ;-) Anyway, this discussion is mostly academic and opinion-based. Commented Jan 27, 2020 at 18:03

I'm sure there were plenty of early "RISC" engines which took on the order of 8 cycles per instruction. One cycle to fetch the instruction, one to access the registers, one to store the result, one to increment the instruction counter. That's 4, but the fetch may have taken several.

(In case anyone's wondering, I was in meetings with George Radin ca 1975.)


Less historical example: ARM (Advanced RISC Machines...) Cortex-M4 has many (though a clear minority) instructions that execute in more than one cycle.

See this list: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439b/CHDDIGAC.html

Cycle count gets less clear when pipelining or dual-issue is introduced (like in the Cortex-M7)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .