ISAs define things like instruction lengths and the instructions themselves and there are some things that I do not understand.

  • Does the instruction length (the amount of bits) affect the amount of instructions that can be performed in a clock cycle?
  • I have tried to do some research on what really determines the amount of instructions that can be performed in a cycle (which led to the question above), but without luck. Is the CPI always variable or is there a specific amount of cycles it takes for certain instructions to be performed, like maybe a "a plain load instruction always takes one cycle"?
  • What sort of processor are you interested in? Go back to an 8080 and it's a lot easier to explain what's going on than a Coffee Lake i7. Commented Feb 14, 2018 at 22:22
  • This is a lot simpler in fixed-size instruction sets like MIPS :)
    – amon
    Commented Feb 14, 2018 at 22:33
  • @PhilipKendall Well I am actually thinking more generally than a specific processor..
    – Ukula Udan
    Commented Feb 14, 2018 at 22:34
  • @amon but is it possible to answer this question for a general case rather than for a specific architecture/implementation? Like if the instruction length has an impact on how many cycles it takes for the specific instruction to be performed - isn't that possible to answer in a general way?
    – Ukula Udan
    Commented Feb 14, 2018 at 22:36

4 Answers 4


With modern processors, there is so much translation, caching, re-arranging, speculative execution etc. going on between reading instruction bytes from memory and executing instructions, that your question can hardly be answered. A modern CPU doesn't execute the instruction bytes it reads from memory but some internal product it creates by complex transformations.

It's comparable to a question like "How many characters of C source code can a CPU execute in one clock cycle?" Well, the machine-instruction bytes might be gradually closer to the execution engine of the CPU than C source code, but only gradually. You get the idea...

In the old 1980s days of 8080/Z80/6502 it was easy. Each instruction was documented to take some fixed number of CPU cycles (if decent-speed memory was used). You could create exact timings from executing specifically-designed programs.

Of course, you can apply some common-sense reasoning. Before executing an instruction for the first time, the CPU must have read it from memory. So, a longer instruction takes more time than a shorter one - at the first execution.

If it's inside a loop, then probably from the second iteration on, the instruction is already in the CPU cache, available in a fraction of the RAM access time. Maybe the CPU translates from x86 op-codes to internal instruction words, then the byte length of the original instruction no longer matters after that translation.

If you want to know for a given sequence of instructions, how long it takes to execute them, you either need a perfect simulator software for the specific CPU and memory subsystem you have in mind (modelling all the things I mentioned), or test it by benchmarking. But be aware that in both cases, the results depend not only on your instructions, but also on the CPU type, the relative RAM speed, the initial contents of the CPU cache, and many other factors. Don't be surprised to see real-life run-times differing by a factor of two or more from the theoretic or benchmarking results.

  • "Before executing an instruction for the first time, the CPU must have read it from memory. So, a longer instruction takes more time than a shorter one - at the first execution." - Maybe. Only if the longer instruction is larger enough to require more transfers than the smaller instruction.
    – 8bittree
    Commented Feb 15, 2018 at 18:15
  • @8bittree You're right if you look at a single, isolated instruction. If you look at a larger code block, every instruction is responsible for some percentage of the load time, proportional to its byte length. Commented Feb 15, 2018 at 19:05

The instruction length can affect CPI, but usually only indirectly.

Generally speaking, a modern CPU will have paths from memory to cache and from cache to ALU that allow it to fetch an entire instruction at once, regardless of length1.

As such, it's fairly unusual for the instruction size to directly. At the same time, a CPU never has unlimited cache space. A larger instruction occupies more cache space, limiting the number of instructions that can fit in the cache. That, in turn, leads to a higher likelihood of cache misses, in which case the CPU can end up waiting for main memory.

As to whether CPI is always variable: yes, at least almost always. In particular, resource dependencies between instructions can limit the amount that can be done in any given cycle. Consider a completely serialized task, where each step of the task depends on the previous step.

In such a case, it's essentially impossible to execute more than one instruction per clock (short of re-structuring the problem, which is generally beyond what any CPU will attempt).

At the same time, a modern, high-performance CPU will almost always have at least some capability to execute more than one instruction per cycle if there aren't any dependencies between them. As such, something like:

OR r0, r1, r2
OR r3, r4, r5

...can normally be executed in parallel, if the processor has resources available to do so. We need to know more about the preceding instructions before we can say how long it'll take to execute those instructions. With more complex instructions that involve access to data that might (or might not) be in a cache, etc., the picture becomes even more complex.

  1. Though this is not always guaranteed. For example, an x86 supports instructions with up to 16 bytes of prefixes (plus the instruction itself), so although it's rare in practice, a single instruction can be too large to transfer in a single cycle, at least on some hardware. Even in this case, a large instruction doesn't necessarily reduce CPI--with a trace cache, what gets stored isn't the raw instruction.

Well, if the bottleneck is memory throughput, a smaller instruction-length allows more instructions per byte. Still, using variable-length for greater density or extendability might counter that advantage due to complexity.

Aside from that, it depends.

In simpler cpu-architectures, there is often a specific clock-count for every instruction by design, which might depend on the data for some subset.
Still, interrupts can influence the timing.

In complexer architectures, especially high-performance ones, due to pipelining, out-of-order-execution, sharing of a bus with peripherals and other considerations, things are more difficult.
While there are probably enough execution-units of some types that some subset of instructions won't have to share, and they don't access the outside (memory, devices), many others are influenced by what was done before, and might still be executing.


On a PowerPC processor, every instruction is always four bytes - so the instruction size cannot possibly affect anything.

On an x86 or ia64 processor, instructions are between 1 and 15 bytes (might be 16). Since newer processors can execute more than one instruction per cycle, they need to decode more than one instruction per cycle. That requires two things: Decoding instructions, and finding where the next instruction starts. You can decode several instructions simultaneously by having more than one decoder. But finding where instructions start (fast) is difficult.

For simple instructions, it is possible to determine the length and with that the start of the next instruction very quickly. For complex instructions finding the length of the instruction takes too long to start decoding the next instruction. The result is that in one cycle, these processors can decode multiple instructions, but only up to reaching a complex instruction.

  • Did you mean IA-64 (a.k.a. Itanium) or x86-64? IA-64 has a fixed 128 bit instruction length and is unrelated to x86, other than being created by the same company.
    – 8bittree
    Commented Feb 14, 2018 at 23:02
  • 1
    In fact, it was specifically created as a clean-slate from-scratch designed successor to both Intel x86 and HP PA-RISC and actually has more in common with the latter than the former (and even that isn't very much). It has so little in common with x86 that executing x86 code is dog-slow, even with clever JIT-compiling emulators. Commented Feb 14, 2018 at 23:25

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.