From: user5857@newsgrouper.org.invalid   
      
   BGB  posted:   
      
   > On 12/30/2025 1:36 AM, Anton Ertl wrote:   
   > > BGB  writes:   
   > >> On 12/29/2025 12:35 PM, Anton Ertl wrote:   
   > > [...]   
   > >> One usual downside is that to utilize a 16-bit ISA with a smaller   
   > >> register space, one needs to reuse registers more frequently, which then   
   > >> reduces ILP due to register conflicts. So, smaller code at the expense   
   > >> of worse performance.   
   > >   
   > > For designs like RISC-V C and Thumb2, there is always the option to   
   > > use the uncompressed instruction.  So you may tune your RISC-V   
   > > compiler to prefer registers r8-r15 for those pseudo-registers that   
   > > occur in instructions where such a register allocation may lead to a   
   > > compressed encoding.   
   > >   
   > > Write-after-read and write-after-write does not reduce the IPC of OoO   
   > > implementations.  On the contrary, write-after-read may be beneficial   
   > > by releasing the old physical register for the register name.  And   
   > > designing a compressed CPU instruction set for in-order processing is   
   > > not a good idea for general-purpose computing.   
   > >   
   >   
   > Though, the main places where compressed instructions are likely to   
   > bring meaningful benefit, is on small in-order machines.   
      
   Coincidentally; this is exactly where a fatter-ISA wins big::   
   compare::   
      
        LDD    R7,[IP,R3<<3,DISP32]   
      
   1 instruction, 3 words, 0 wasted registers, cache-hit minimum--against   
      
        AUPIC  Rt,lo(DISP32)   
        SLL    Ri,R3,#3   
        ADD    Rt,Rt,hi(DISP32)   
        ADD    Rt,Rt,Ri   
        LDD    R7,0(Rt)   
      
   5 instructions, 4 words, 2-wasted registers, 4-cycles+cache hit minimum.   
      
   > Any OoO machine is also likely to have a lot of RAM and a decent sized   
   > I$, so much of any benefit is likely to go away in this case.   
      
   s/go away/greatly ameliorated/   
      
   ------------------------   
   > > ILP is a property of a program.  I assume that what you mean is that   
   > > the IPC benefits of more width have quickly diminishing returns on   
   > > in-order machines.   
   > >   
   >   
   > The ILP is a property of the code, yes, but how much exists, and how   
   > much of it is actually usable, is effected by the processor implementation.   
      
   I agree that ILP is more aligned with code than with program.   
   {see above example where 1 instruction does the work of 5}   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)