From: monnier@iro.umontreal.ca   
      
   >> I have come to realize that 32/64 is probably better than 16/32 here,   
   >> primarily in terms of performance, but also helps with code-density (a   
   >> pure 32/64 encoding scheme can beat 16/32 in terms of code-density   
   >> despite only having larger instructions available).   
   >   
   > My 66000 does not even bother with 16-bit instructions--and still ends   
   > up requiring fewer instruction count than RISC-V. {32, 64, 96, 128, 160}   
   > are the instruction sizes; with no instructions ever requiring constants   
   > to be assembled.   
      
   Indeed, My 66000 aims for "fat" instructions so as to try and reduce   
   instruction counts.  That should hopefully result in an efficient ISA:   
   fewer instructions should cost less runtime resources (as long as they   
   don't get split into more μops).   
      
   > Most of the MOV instructions in My 66000 are found::   
   > a) before a call--moving values  to argument  positions,   
   > b) after  a call--moving results to post-call positions,   
   > c) around loops --moving values for next loop iteration.   
   [...]   
   > I suspect that argument setup before and result take-down after call   
   > would have quite a bit of parallelism.  I suspect that moving fields   
   > around for the next loop iteration would have significant parallelism.   
      
   Are you saying that you expect the efficiency of My 66000 could be   
   improved by adding some way to express those moves in a better way?   
   A key element of the Mill is/was its ability to "permute" its belt   
   elements in a single cycle.  I still don't fully understand how this is   
   encoded in the ISA and implemented in hardware, but it sounds like   
   you're hinting in the same direction: some kind of "parallel move"   
   instruction with many inputs and many outputs.   
      
      
           Stefan   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)