I'm learning a CPU architecture and currently found some high-level description of Intel x86_64 CPUs architecture. By the high level description I mean something like the following micro-op flow (might be wrong, this is how I currently see it):

1. Fetching code from memory
2. Caching the code in L1I cache
3. Activating Legacy Decode Pipeline
4. Put the decoded micro ops into the Decoded ICache and to the micro-ops queue (a.k.a IDQ)
5. Send micro-ops from the micro-op queue to RAT (a.k.a Renamer)
6. Allocate necessary resources and send micro-ops to the Reservation Station (a.k.a. Scheduler)
7. Dispatch micro-ops to the appropriate port
8. Write the result of the micro-ops to the writeback bus
9. Retire the micro-op

The question is if it is possible for micro-op to pass multiple pipeline stages for a single clock cycle?

For example:

  1. A bunch of micro-ops are fetched from the Decoded ICache and put to the IDQ then the Renamer moves the micro-ops to the RS during the same clock cycle

  2. Renamer moving a micro-op from IDQ to RS and then RS dispatches the micro-op to an issue port during the same clock cycle

  3. When OOO core finishes execution of a micro-op its result is written to the writeback bus and then the micro-op is retired during the same clock-cycle.

Is it technically possible?


1 Answer 1


Yes and no.

You could make a processor core that might do the equivalent to your above sequence in one clock cycle, but it would happen at the cost of higher propagation delay, which would drive your clock rate down.

As a simplistic example, say that the propagation delay at each of your nine steps is the same. You've adjusted your clock so that each step is completed with some safe margin in propagation delay.

If you can keep your pipeline full all the time (which can't be done -- but let's say you can) then at each clock cycle an instruction starts and an instruction retires.

Now combine those pipeline steps in groups of three. Woo-hoo! Your pipeline is shorter! But your propagation delay has gone up -- so now you have to divide your clock rate by three, or nearly so.

So -- if you keep your pipeline full -- you issue an instruction each clock cycle, retire an instruction each clock cycle and your clock is three times slower than it was.

Which executes programs faster?

  • \$\begingroup\$ If you can keep your pipeline full all the time (which can't be done Could you give an idea why? It is possible to write a code that would utilize the full retirement bandwidth. \$\endgroup\$
    – Some Name
    Apr 10, 2020 at 16:46
  • 1
    \$\begingroup\$ Do a web search on "pipeline hazard". Basically, if some operation is demanded that either depends on data that isn't available yet, or that branches the processor, then the pipeline will need to be stalled or flushed. A good part of modern compiler optimization is generating machine code that minimize pipeline hazards; a good part of modern processor design is designing pipelines that have minimal exposure to hazards. It's a great big subject that won't fit into a post on Stackexchange. \$\endgroup\$
    – TimWescott
    Apr 10, 2020 at 17:33
  • \$\begingroup\$ Ah, that what you meant by "can't be done". I meant that it was perfectly possible to write such code that stalls neither FrontEnd nor BackEnd and does not suffer from mispredict/misspeculate. A loop consisting of a few nops would be an example since nops are retired without going to RS. \$\endgroup\$
    – Some Name
    Apr 10, 2020 at 17:39
  • 1
    \$\begingroup\$ One can write contrived code that won't cause hazards in a given pipeline, yes. But in general you can't write code to get some arbitrary job done that also won't cause pipeline hazards. \$\endgroup\$
    – TimWescott
    Apr 10, 2020 at 17:42

Your Answer

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

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