Did any RISC CPU ever take more than one clock cycle per instruction?

Question

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?

Answer 1

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).

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.)

Answer 6

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)