From: cr88192@gmail.com   
      
   On 8/20/2025 6:17 PM, EricP wrote:   
   > BGB wrote:   
   >> On 8/17/2025 12:35 PM, EricP wrote:   
   >>>   
   >>> The question is whether in 1975 main memory is so expensive that   
   >>> we cannot afford the wasted space of a fixed 32-bit ISA.   
   >>> In 1975 the widely available DRAM was the Intel 1103 1k*1b.   
   >>> The 4kb drams were just making to customers, 16kb were preliminary.   
   >>>   
   >>> Looking at the instruction set usage of VAX in   
   >>>   
   >>> Measurement and Analysis of Instruction Use in VAX 780, 1982   
   >>> https://dl.acm.org/doi/pdf/10.1145/1067649.801709   
   >>>   
   >>> we see that the top 25 instructions covers about 80-90% of the usage,   
   >>> and many of them would fit into 2 or 3 bytes.   
   >>> A fixed 32-bit instruction would waste 1 to 2 bytes on most   
   >>> instructions.   
   >>>   
   >>> But a fixed 32-bit instruction is very much easier to fetch and   
   >>> decode needs a lot less logic for shifting prefetch buffers,   
   >>> compared to, say, variable length 1 to 12 bytes.   
   >>>   
   >>   
   >> When code/density is the goal, a 16/32 RISC can do well.   
   >>   
   >> Can note:   
   >>   Maximizing code density often prefers fewer registers;   
   >>   For 16-bit instructions, 8 or 16 registers is good;   
   >>   8 is rather limiting;   
   >>   32 registers uses too many bits.   
   >   
   > I'm assuming 16 32-bit registers, plus a separate RIP.   
   > The 74172 is a single chip 3 port 16*2b register file, 1R,1W,1RW.   
   > With just 16 registers there would be no zero register.   
   >   
   > The 4-bit register allows many 2-byte accumulate style instructions   
   > (where a register is both source and dest)   
   > 8-bit opcode plus two 4-bit registers,   
   > or a 12-bit opcode, one 4-bit register, and an immediate 1-8 bytes.   
   >   
      
   Yeah.   
      
   SuperH had:   
      ZZZZnnnnmmmmZZZZ  //2R   
      ZZZZnnnniiiiiiii  //2RI (Imm8)   
      ZZZZnnnnZZZZZZZZ  //1R   
      
      
   For BJX2/XG1, had went with:   
      ZZZZZZZZnnnnmmmm   
   But, in retrospect, this layout was inferior to the one SuperH had used   
   (and I almost would have just been better off doing a clean-up of the SH   
   encoding scheme than moving the bits around).   
      
   Though, this happened during a transition between B32V and BSR1, where:   
   B32V was basically a bare-metal version of SH;   
   BSR1 was an instruction repack (with tweaks to try make it more   
   competitive with MSP430 while still remaining Load/Store);   
   BJX2 was basically rebuilding all the stuff from BJX1 on top of BSR1's   
   encoding scheme (which then mutated more).   
      
      
   At first, BJX2's 32-bit ops were a prefix:   
      111P-YYWY-qnmo-oooo ZZZZ-ZZZZ-nnnn-mmmm   
      
   But, then got reorganized:   
      111P-YYWY-nnnn-mmmm ZZZZ-qnmo-oooo-ZZZZ   
      
   Originally, this repack was partly because I had ended up designing some   
   Imm9/Disp9 encodings as it quickly became obvious that Imm5/Disp5 was   
   insufficient. But, I had designed the new instructions to have the Imm   
   field not be totally dog-chewed, so ended up changing the layout. Then   
   ended up changing the encoding for the 3R instructions to better match   
   that of the new Imm9 encodings.   
      
   Then, XG2:   
      NMOP-YYwY-nnnn-mmmm ZZZZ-qnmo-oooo-ZZZZ  //3R   
      
   Which moved entirely over to 32/64/96 bit encodings in exchange for   
   being able to directly encode 64 GPRs in 32-bit encodings for the whole ISA.   
      
      
   In the original BJX2 (later renamed XG1), only a small subset having   
   direct access to the higher numbered registers; and other instructions   
   using 64-bit encodings.   
      
   Though, ironically, XG2 never surpassed XG1 in terms of code-density;   
   but being able to use 64 registers "pretty much everywhere" was (mostly)   
   a good thing for performance.   
      
      
   For XG3, there was another repack:   
      ZZZZ-oooooo-mmmmmm-ZZZZ-nnnnnn-qY-YYPw  //3R   
      
   But, this was partly to allow it to co-exist with RISC-V.   
      
   Technically, still has conditional instructions, but these were demoted   
   to optional; as if one did a primarily RISC-V core, with an XG3 subset   
   as an ISA extension, they might not necessarily want to deal with the   
   added architectural state of a 'T' bit.   
      
   BGBCC doesn't currently use it by default.   
      
   Was also able to figure out how to make the encoding less dog chewed   
   than either XG2 or RISC-V.   
      
      
   Though, ironically, the full merits of XG3 are only really visible in   
   cases where XG1 and XG2 are dropped. But, it has a new boat-anchor in   
   that it now assumes coexistence with RISC-V (which itself has a fair bit   
   of dog chew).   
      
   And, if the goal is RISC-V first, then likely the design of XG3 is a big   
   ask; it being essentially its own ISA.   
      
   Though, while giving fairly solid performance, XG3 currently hasn't   
   matched the code density of its predecessors (either XG1 or XG2). It is   
   more like "RISC-V but faster".   
      
   And, needing to use mode changes to access XG3 or RV-C is a little ugly.   
      
      
      
   Though, OTOH, RISC-V land is annoying in a way; lots of people being   
   like "RV-V will save us from all our performance woes!". Vs, realizing   
   that some issues need to be addressed in the integer ISA, and SIMD and   
   auto-vectorization will not address inefficiencies in the integer ISA.   
      
      
   Though, I have seen glimmers of hope that other people in RV land   
   realize this...   
      
      
   > A flags register allows 2-byte short conditional branch instructions,   
   > 8-bit opcode and 8-bit offset. With no flags register the shortest   
   > conditional branch would be 3 bytes as it needs a register specifier.   
   >   
      
   Yeah, "BT/BF Disp8".   
      
      
   > If one is doing variable byte length instructions then   
   > it allows the highest usage frequency to be most compact possible.   
   > Eg. an ADD with 32-bit immediate in 6 bytes.   
   >   
      
      
   In BSR1, I had experimented with:   
      LDIZ  Imm12u, R0  //R0=Imm12   
      LDISH Imm8u       //R0=(R0<<8)|Umm8u   
      OP    Imm4R, Rn   //OP [(R0<<4)|Imm4u], Rn   
      
   Which allowed Imm24 in 6 bytes or Imm32 in 8 bytes.   
      Granted, as 3 or 4 instructions.   
      
   Though, this began the process of allowing the assembler to fake more   
   complex instructions which would decompose into simpler instructions.   
      
      
   But, this was not kept, and in BJX2 was mostly replaced with:   
      LDIZ  Imm24u, R0   
      OP    R0, Rn   
      
   Then, when I added Jumbo Prefixes:   
      OP   Rm, Imm33s, Rn   
      
   Some extensions of RISC-V support Imm32 in 48-bit ops, but this burns   
   through lots of encoding space.   
      
      iiiiiiii-iiiiiiii iiiiiiii-iiiiiiii zzzz-nnnnn-z0-11111   
      
   This doesn't go very far.   
      
      
   >> Can note ISAs with 16 bit encodings:   
   >>   PDP-11: 8 registers   
   >>   M68K  : 2x 8 (A and D)   
   >>   MSP430: 16   
   >>   Thumb : 8|16   
   >>   RV-C  : 8|32   
   >>   SuperH: 16   
   >>   XG1   : 16|32 (Mostly 16)   
   >   
   > The saving for fixed 32-bit instructions is that it only needs to   
   > prefetch aligned 4 bytes ahead of the current instruction to maintain   
   > 1 decode per clock.   
   >   
   > With variable length instructions from 1 to 12 bytes it could need   
   > a 16 byte fetch buffer to maintain that decode rate.   
   > And a 16 byte variable shifter (collapsing buffer) is much more logic.   
   >   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)