From: user5857@newsgrouper.org.invalid   
      
   Robert Finch  posted:   
      
   > On 2025-12-19 6:36 p.m., MitchAlsup wrote:   
   > >   
   > > BGB  posted:   
   > > --------------------------------------------   
   > >   
   > > Probably no conducive to FPGA implementations due to LUT count and   
   > > special memories {predictors, ..., TLBs, staging buffers, ...}   
   > >   
   > >> So, while a 4 or 5 wide in-order design could be possible, pretty much   
   > >> no normal code is going to have enough ILP to make it worthwhile over 2   
   > >> or 3.   
   > >   
   > > 1-wide 0.7 IPC   
   > > 2-wide 1.0 IPC gain of 50%   
   > > 3-wide 1.4 IPC gain of 40%   
   > > 6-wide 2.2 IPC gain of 50% from doubling the width   
   > > 10wide 3.2 IPC gain of 50% from almost doubling width   
   > >   
   > >> Also 2 or 3 works reasonably well with a 96-bit fetch:   
   > >   
   > > But Fetches ae 128-bits wide !!! and the average instruction is 35-bits   
   wide.   
   >   
   > Could the average instruction size be an argument for the use of wider   
   > (40-bits) instructions?   
      
   I think that is an independent variable, especially if you have variable   
   length instructions. Also note: My CARRY instruction concatenates 2-bits   
   on up to 8 subsequent instructions--but it is used seldom enough to avoid   
   disturbing the long term average bit count.   
      
   >                         One would think that the instruction should be a   
   > bit wider than average. Bin trying to shrink Qupls4 instructions down to   
   > 40-bits for Qupls5. The odd size is not that great an issue if variable   
   > lengths are supported.   
   >   
   > > ------------------------   
   > >> One trick here could be to precompute a lot of this when fetching cache   
   > >> lines, though a full instruction length could not be determined at fetch   
   > >> time if the instruction crosses a cache line unless we have also fetched   
   > >> the next cache line. Full instruction length could be determine in   
   > >> advance (at fetch time) if it always fetches both cache-lines and then   
   > >> determines the lengths for one of them before writing to the cache   
   > >> (possibly if the next line is fetched, it contents are not written to   
   > >> the cache as lengths can't be fully determined yet).   
   > >   
   > > All of the above was solved in Athlon, and then made 3× smaller in Opteron   
   > > at the cost of 1 pipe stage in DECODE.   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)