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