[continued from previous message]   
      
      iiii-iiii-iiii-iiii-zzzz-0jjj-jj11-1111  //Jumbo Prefix (Imm, Typical)   
        Extends Imm10 to Imm33, leaves 4 bits for sub-operation.   
        If prefix is used with a Reg5 op, extend reg fields to 6-bit.   
      
   Keeping register fields consistent helps with superscalar. It more   
   matters here that the low order bits remain in the same place.   
      
   Keeping immediate fields consistent helps with "everything not being a   
   massive pain". I would assume all normal 3RI immediate and displacement   
   instructions have the same size and layout of immediate. However,   
   depending on instruction it may change scale. As I see it, scale   
   changing is preferable to bit-slicing though.   
      
      
   While less elegant to have a mix of 5 and 6 bit register encodings,   
   doing so could be more economical regarding the use of encoding space   
   compared with purely 6 bit (while being less limiting compared with pure   
   5 bit).   
      
   Possibly, one could have a semi-split space where, say:   
      R0..R31 are primarily integer registers;   
      R32..R63 are primarily FPU and SIMD registers;   
      A lot of core operations have access to the entire register space;   
      Non-core operations might be specific to the low or high 32;   
      SIMD-128 ops could use 5b register fields,   
        but still have the full register space   
      
      
   The semi-split scheme could work well in medium to low register pressure   
   scenarios; with 6-bit core ops helping with high register pressure.   
      
   Likely, at least, all the Load/Store and basic ALU operations need Reg6.   
      
      
   Not having 16-bit ops could simplify implementation slightly and also   
   allow better performance with a simpler implementation. One other option   
   being to allow 16 bit ops, but with the caveat that using them may   
   reduce performance (with the compiler ideally keeping performance   
   optimized using primarily 32-bit encodings wherever possible, and   
   maintaining a 32-bit alignment of the instruction stream).   
      
   Where, in such a case, 16-bit ops could be left either for low-traffic   
   code or for size optimized binaries.   
      
   ...   
      
      
   Though, more elegant (and possibly also highest performance) could be to   
   just go for 32/64/96 bit instructions with 6-bit register fields (also,   
   any lower-probability ops can use 64-bit encodings; though, at the cost   
   of code density).   
      
      
   Just another random pull here...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)