From: monnier@iro.umontreal.ca   
      
   BTW, when discussing ISA compactness, I usually see it measured by   
   comparing the size of the code segment in typical executables.   
      
   I understand that it's as good a measure as any and it's one that's   
   fairly easily available, but at the same time it's not necessarily one   
   that actually matters since I expect that it affects a usually fairly   
   small proportion of the total ROM/Flash/disk space.   
      
   I wonder if there have been other studies to explore other impacts such   
   as run time, or cache miss rate.   
      
      
           Stefan   
      
      
   EricP [2025-12-29 09:54:30] wrote:   
      
   > Thomas Koenig wrote:   
   >> Stefan Monnier  schrieb:   
   >>>>> Well, Mitch claims average 35 bits per instructions, that means about   
   >>>>> 90% utilization of decoders, so not bad.   
   >>>> His minimum instruction size is 32 bits, but I was going for 16 bits.   
   >>> BTW, my understanding of Mitch's design is that this is related to   
   >>> instruction complexity: if you support 16bit instructions, it means you   
   >>> support instructions which presumably don't do very much work because   
   >>> it's hard to express a lot of "work to do" in 16bit.   
   >> A bit of statistics on that.   
   >> Using a primitive Perl script to catch occurences, on a recent   
   >> My 66000 cmopiler, of the shape   
   >> 	[op] Ra,Ra,Rb   
   >> 	[op] Ra,Rb,Ra   
   >> 	[op] Ra,#n,Ra   
   >> 	[op] Ra,Ra,#n   
   >> 	[op] Ra,Rb   
   >> where |n| < 32, which could be a reasonable approximation of a   
   >> compressed instruction set, yields 14.9% (Perl), 16.6% (gnuplot)   
   >> and 23.9% (GSL) of such instructions.  Potential space savings   
   >> would be a bit less than half that.   
   >> Better compression schemes are certainly possible, but I think the   
   >> disadvantages of having more complex encodings outweigh any   
   >> potential savings in instruction size.   
   >   
   > The % associations you measured above might just be coincidence.   
   >   
   > I have assumed for a compiler to choose between two instruction formats,   
   > a 2-register Rsd1 = Rsd1 OP Rs2, and a 3-register Rd1 = Rs2 OP Rs3,   
   > that the register allocator would check if either operand was alive after   
   > the OP, and if not then that source register can be reused as the dest.   
   > For some ISA that may allow a shorter instruction format to be used.   
   >   
   > Your stats above assume the compiler is performing this optimization   
   > but since My 66000 does not have short format instructions the compiler   
   > would have no reason to do so. Or the compiler might be doing this   
   > optimization anyways for other ISA such as x86/x64 which do have   
   > shorter formats.   
   >   
   > So the % numbers you measured might just be coincidence and could be low.   
   > An ISA with both short 2- and long 3- register formats like RV where there   
   > is an incentive to do this optimization might provide stats confirmation.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)