From: anton@mips.complang.tuwien.ac.at   
      
   Stefan Monnier  writes:   
   >The way I see it, the problem is that after   
   >   
   >    MULTIMOVE {R1,R2} <= {R6,R8}   
   >   
   >the preceding instruction which generated a result into R6 now needs to   
   >put the result into both R6 and R1.   
      
   Not necessarily.  It can also mean that in the register map both the   
   entry for R6 and R1 point to the same physical register (where the   
   result of the preceding instruction that wrote into R6 landed).  That   
   would make it necessary to reference-count the physical registers.   
      
   Given that the register renamer in Lion Cove manages to perform 7.02   
   dependent (and 7.25 independent) moves per cycle, I expect that it   
   uses a technique like I outlined above.   
      
   >Maybe a way to avoid that problem   
   >is to make the renaming architectural.  I.e. add a "register renaming   
   >table" (RRT), and introduce the instruction RENAME which changes   
   >that RRT.  Whenever an instruction wants to read register Rn, the actual   
   >architectural register we'll read is obtained by passing `n` through RRT.   
      
   All of that happens with microarchitectural renaming (your RRT is   
   called RAT (register alias table), however).  Your "RENAME"   
   instruction is called "MOV".  Why make the RAT architectural?   
      
   - anton   
   --   
   'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'   
     Mitch Alsup,    
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)