From: user5857@newsgrouper.org.invalid   
      
   Stefan Monnier  posted:   
      
   > 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.   
      
   Cache miss rate is proportional to SQRT(code size).   
      
   And In my opinion::   
   Small changes are essentially irrelevant when there is a wide range   
   of implementations on which the code runs.   
      
   >   
   >         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)