From: monnier@iro.umontreal.ca   
      
   >> > For argument setup (calling side) one needs MOV {R1..R5},{Rm,Rn,Rj,Rk,Rl}   
   >> > For returning values (calling side)   needs MOV {Rm,Rn,Rj},{R1..R3}   
   >> In terms of encoding, these are fairly easy and could each fit within   
   >> a 32bit instruction.   
   > You are going to put 6×5-bit fields in a single 32-bit instruction with   
   > a 6-bit Major OpCode ?!?!   
      
   AFAICT we need "only" 5x 5bit (if we hardcode the destination to be   
   R1..R5 in one instruction and if we hardcode R1..R5 as the source   
   registers in the other instruction).   
      
   > I would like to see it done.   
      
   It's definitely tight (we still need some way to indicate how many   
   registers we want to move), but it seems within the realm of possible.   
   Whether it "pays for its encoding cost" is a separate question.   
      
   > I can see an encoding that would provide a "bunch of MOVs/Renames"   
   > but only if I disobey a principle tenet of ISA encoding {One that RISC-V   
   > threw away on day 1} and that is; the register specification fields are   
   > at fixed locations. It is this tenet that removed some    
   > logic before multiplexing the specifiers into the RF decoder. The fixed   
   > position argument has neither the logic nor the multiplexer, RF specifiers   
   > are wired directly to the RF/Renamer decoder ports directly.   
      
   Clearly, if we want a "multi-move" instruction, it has to break such   
   assumptions.  I was hoping that maybe it's OK to break it because   
   [ assuming the execution doesn't really exist because its all done in   
   the renamer, ] the "execution" of this instruction doesn't actually need   
   that data.   
      
   > It is also not exactly clear how one "makes" an instruction with   
   > {2,3,4,5,6,7} writes traverse the pipeline smoothly. I took serious   
   > consideration to find an smooth solution to even {2} results, and for   
   > this I built an accumulator attached to the 3-operand+1-result   
   > function units where the added operand is read once (if needed) and   
   > written once (if needed) often not requiring ANY RF activity in   
   > support of the CARRY variable itself.   
      
   I'm not really surprised.  🙁   
   The only way I can see it work is if we can arrange for such   
   a multi-move to *not* have multiple outputs, and instead be treated as   
   "just a renaming".   
      
   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.  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.   
   [ Any write to a register would presumably reset that register's entry in   
     RRT, to avoid too many headaches for ASM programmers.  ]   
   All problems can be solved by adding a level of indirection, they say.   
      
      
           Stefan   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)