home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.arch      Apparently more than just beeps & boops      131,241 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 129,455 of 131,241   
   BGB to EricP   
   Re: VAX (2/2)   
   20 Aug 25 23:50:52   
   
   [continued from previous message]   
      
   > I was thinking the variable instruction buffer shifter could be built   
   > from tri-state buffers in a cross-bar rather than muxes.   
   >   
   > The difference for supporting variable aligned 16-bit instructions and   
   > byte aligned is that bytes doubles the number of tri-state buffers.   
   >   
      
   If the smallest instruction size is 16 bits, it simplifies things   
   considerably vs 8 bits.   
      
   If the smallest size is 32-bits, it simplifies things even more.   
      Fixed length is the simplest case though.   
      
      
   As noted, 32/64/96 bit fetch isn't too difficult though.   
      
   For 64/96 bit instructions though, mostly want to be able to (mostly)   
   treat it like a superscalar fetch of 2 or 3 32-bit instructions.   
      
   In my CPU, I ended up making it so that only 32-bit instructions support   
   superscalar; whereas 16 and 64/96 bit instructions are scalar only.   
      
   Superscalar only works with native alignment though (for RISC-V), and   
   for XG3, 32-bit instruction alignment is mandatory.   
      
      
   As noted, in terms of code density, a few of the stronger options are   
   Thumb2 and RV-C, which have 16 bits as the smallest size.   
      
      
   I once experimented with having a range of 24-bit instructions, but the   
   hair this added (combined with the fairly little gain in terms of code   
   density) showed this was rather not worth it.   
      
      
   ...   
      
      
   >> In my recent fiddling for trying to design a pair encoding for XG3,   
   >> can note the top-used instructions are mostly, it seems (non Ld/St):   
   >>   ADD   Rs, 0, Rd    //MOV     Rs, Rd   
   >>   ADD   X0, Imm, Rd  //MOV     Imm, Rd   
   >>   ADDW  Rs, 0, Rd    //EXTS.L  Rs, Rd   
   >>   ADDW  Rd, Imm, Rd  //ADDW    Imm, Rd   
   >>   ADD   Rd, Imm, Rd  //ADD     Imm, Rd   
   >>   
   >> Followed by:   
   >>   ADDWU Rs, 0, Rd    //EXTU.L  Rs, Rd   
   >>   ADDWU Rd, Imm, Rd  //ADDWu   Imm, Rd   
   >>   ADDW  Rd, Rs, Rd   //ADDW    Rs, Rd   
   >>   ADD   Rd, Rs, Rd   //ADD     Rs, Rd   
   >>   ADDWU Rd, Rs, Rd   //ADDWU   Rs, Rd   
   >>   
   >> Most every other ALU instruction and usage pattern either follows a   
   >> bit further behind or could not be expressed in a 16-bit op.   
   >>   
   >> For Load/Store:   
   >>   SD  Rn, Disp(SP)   
   >>   LD  Rn, Disp(SP)   
   >>   LW  Rn, Disp(SP)   
   >>   SW  Rn, Disp(SP)   
   >>   
   >>   LD  Rn, Disp(Rm)   
   >>   LW  Rn, Disp(Rm)   
   >>   SD  Rn, Disp(Rm)   
   >>   SW  Rn, Disp(Rm)   
   >>   
   >>   
   >> For registers, there is a split:   
   >>   Leaf functions:   
   >>     R10..R17, R28..R31 dominate.   
   >>   Non-Leaf functions:   
   >>     R10, R18..R27, R8/R9   
   >>   
   >> For 3-bit configurations:   
   >>   R8..R15                             Reg3A   
   >>   R18/R19, R20/R21, R26/R27, R10/R11  Reg3B   
   >>   
   >> Reg3B was a bit hacky, but had similar hit rates but uses less   
   >> encoding space than using a 4-bit R8..R23 (saving 1 bit on the   
   >> relevant scenarios).   
   >>   
   >>   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca