From: ThatWouldBeTelling@thevillage.com   
      
   MitchAlsup wrote:   
   > EricP  posted:   
   >   
   >> John Savard wrote:   
   >>> On Sun, 21 Dec 2025 20:32:44 +0000, MitchAlsup wrote:   
   >>>>> On Thu, 18 Dec 2025 21:29:00 +0000, MitchAlsup wrote:   
   >>>>>> Or in other words, if you can decode K-instructions per cycle, you'd   
   >>>>>> better be able to execute K-instructions per cycle--or you have a   
   >>>>>> serious blockage in your pipeline.   
   >>>> Not a typo--the part of the pipeline which is  narrowest is   
   >>>> the part that limits performance. I suggest strongly that you should not   
   >>>> make/allow the decoder to play that part.   
   >>> I agree - and strongly, too - that the decoder ought not to be the part   
   >>> that limits performance.   
   >>>   
   >>> But what I quoted says that the execution unit ought not to be the part   
   >>> that limits performance, with the implication that it's OK if the decoder   
   >>> does instead. That's why I said it must be a typo.   
   >>>   
   >>> So I think you need to look a second time at what you wrote; it's natural   
   >>> for people to see what they expect to see, and so I think you looked at   
   >>> it, and didn't see the typo that was there.   
   >>>   
   >>> John Savard   
   >> There are two kinds of stalls:   
   >> stalls in the serial front end I-cache, Fetch or Decode stages because   
   >> of *too little work* (starvation due to input latency),   
   >> and stalls in the back end Execute or Writeback stages because   
   >> of *too much work* (resource exhaustion).   
   >   
   > DECODE latency increases when:   
   > a) there is no instruction(s) to decode   
   > b) there is no address from which to fetch   
   > c) when there is no translation of the fetch address   
   >   
   > a) is a cache miss   
   > b) is an indirect control transfer   
   > c) is a TLB miss   
   >   
   > And there may be additional cases of instruction buffer hiccups.   
      
   Yes. Also Decode generated stalls - pipeline drain.   
   Rename stall for new dest register pool exhaustion.   
      
   >> The front end stalls inject bubbles into the pipeline,   
   >> whereas back end stalls can allow younger bubbles to be compressed out.   
   >   
   > How In-Order your thinking is. GBOoO machine do not inject bubbles.   
      
   You get bubbles if you overload their resources no matter how GB it is.   
      
   For example, if all the reservation stations for a FU are in use then   
   Dispatch has to stall, which stalls the whole front end.   
   A compacting pipeline in the front end can compress out those bubbles   
   but it eventually stalls too.   
      
   Dependency stalls - all the uOps in reservation stations are waiting   
   on other results. Serialization stalls.   
      
   If a design is doing dynamic register file read port assignment and   
   runs out of read ports. Resource exhaustion stalls.   
      
   Multiple uOps are ready but only one can launch. Scheduling stalls.   
      
   >> If I have to stall, I want it in the back end.   
   >   
   > If I have to stall I want it based on "realized" latency.   
   >   
   >> It has to do with catching up after a stall.   
   >   
   > Which is why you do not inject bubbles...   
      
   It's not me doing it. I blame the speed of light.   
      
   >> If a core stalls for 3 clocks, then in order to average 1 IPC   
   >> it must retire 2 instructions per clock for the next 3 clocks.   
   >> And it can only do that if it has a backlog of work ready to execute.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)