From: cr88192@gmail.com   
      
   On 8/31/2025 1:17 AM, John Savard wrote:   
   > I have had so much success in adjusting Concertina II to achieve my goals   
   > more fully than I had thought possible... that I now think that it may be   
   > possible to proceed from Concertina II to a design which gets rid of the   
   > one feature of Concertina II that has been the most controversial.   
   >   
   > Yes, I think that I could actually do without block structure.   
   >   
   > What would Concertina III look like?   
   >   
   > Well, the basic instruction set would be similar to that of Concertina II.   
   > But the P bits would be taken out of the operate instructions, and so   
   > would the option of replacing a register specification by a pseudo-   
   > immediate pointer.   
   >   
   > The tiny gaps between the opcodes of some instructions to squeeze out   
   > space for block headers would be removed.   
   >   
   > But the big spaces for the shortest block header prefixes would be what is   
   > used for doing without headers.   
   >   
   > Instead of a block header being used to indicate code consisting of   
   > variable-length instructions, variable-length instructions would be   
   > contained within a sequence of pairs of 32-bit instructions of this form:   
   >   
   > 11110xx(17 bits)(8 bits)   
   > 11111x(9 bits)(17 bits)   
   >   
   > Instructions could be 17 bits long, 34 bits long, 51 bits long, and so on,   
   > any multiple of 17 bits in length.   
   >   
   > In the first instruction slot of the pair, the two bits xx indicate, for   
   > the two 17-bit regions of the variable-length instruction area that start   
   > in it, if they are the first 17-bit area of an instruction. The second   
   > instruction slot only contains the start of one 17-bit area, so only one   
   > bit x is needed. Since 17 is an odd number, this meshes perfectly with the   
   > fact that the 17-bit area which straddles both words isn't split evenly,   
   > but rather one extra bit of it is in the second 32-bit instruction slot.   
   >   
   > I had been hoping to use 18-bit areas instead, but after re-checking my   
   > calculations, I found there just wasn't enough opcode space.   
   >   
   > Long instructions that contain immediates would not be part of variable-   
   > length instruction code. Instead, their lengths would be multiples of 32   
   > bits, making them part of ordinary code with 32-bit instructions.   
   >   
   > Their form would be like this:   
   >   
   > 32-bit immediate:   
   >   
   > 1010(12 bits)(16 bits)   
   > 10111(11 bits)(16 bits)'   
   >   
   > where the first parenthesized area belongs to the instruction, and the   
   > second to the immediate.   
   >   
   > 48-bit immediate:   
   >   
   > 1010(12 bits)(16 bits)   
   > 10110(11 bits)(16 bits)   
   > 10111(11 bits)(16 bits)   
   >   
   > 64-bit immediate:   
   >   
   > 1010(12 bits)(16 bits)   
   > 10110(3 bits)(24 bits)   
   > 10111(3 bits)(24 bits)   
   >   
   > Since the instruction, exclusive of the immediate, really only needs 12   
   > bits - 7 bit opcode, and 5 bit destination register - in each case there's   
   > enough additional space for the instruction to begin with a few bits that   
   > indicates its length, so that decoding is simple.   
   >   
   > The scheme is not really space-efficient.   
   >   
   > But the question that I really have is... is this really any better than   
   > having block headers? Or is it just as bad, just as complicated?   
   >   
      
      
   How about, say, 16/32/48/64/96:   
                          xxxx-xxxx-xxxx-xxx0  //16 bit   
      xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxyy-yyy1  //32 bit   
      xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xx11-1111  //64/48/96 bit prefix   
      
   Already elaborate enough...   
      
      
      
   Where:   
      Prefix+16b = 48b   
      Prefix+32b = 64b   
      Prefix+Prefix+32b = 96b   
      
   This leaves 15 bits of encoding space for 16 bit ops.   
      
   Nominally, the 16-bit ops can have 16 registers.   
      Preferably:   
        8 scratch, 8 callee save   
        Roughly the first 4-8 argument registers.   
   A few cases could have 32 registers.   
      
   For 32-bit ops, 32 or 64 registers.   
      
   Might map out register space as, say:   
      R0..R3: ZR/LR/SP/GP   
      R4..R7: Scratch   
      R8..R15: Scratch / Arg   
      R16..R31: Callee Save   
   For high 32:   
      R32..R47: Scratch   
      R48..R63: Callee Save   
      
      
   With 16 bit ops maybe having maybe R8..R23 (or R16..R24,R8..R15) for the   
   Reg4 field.   
      
   Some possible 16-bit ops:   
      00in-nnnn-iiii-0000  ADD  Imm5s, Rn5  //"ADD 0, R0" = TRAP   
      01in-nnnn-iiii-0000  MOV  Imm5s, Rn5   
      10mn-nnnn-mmmm-0000  ADD  Rm5, Rn5   
      11mn-nnnn-mmmm-0000  MOV  Rm5, Rn5   
      
      0000-nnnn-iiii-0010  ADDW Imm4u, Rn4  //ADD Imm, 32-bit sign extension   
      0001-nnnn-mmmm-0010  SUB  Rm4, Rn4   
      0010-nnnn-mmmm-0010  ADDW Imm4n, Rn4  //ADD Imm, 32-bit sign extension   
      0011-nnnn-mmmm-0010  MOVW Rm4, Rn4    //MOV with 32-bit sign extension   
      0100-nnnn-mmmm-0010  ADDW Rm4, Rn4   
      0101-nnnn-mmmm-0010  AND  Rm4, Rn4   
      0110-nnnn-mmmm-0010  OR   Rm4, Rn4   
      0111-nnnn-mmmm-0010  XOR  Rm4, Rn4   
      
      1000-dddd-dddd-0010  BRA  Disp8   
      ...   
      
      0ddd-nnnn-mmmm-0100  LW   Disp3(Rm4), Rn4   
      1ddd-nnnn-mmmm-0100  SW   Disp3(Rm4), Rn4   
      0ddd-nnnn-mmmm-0110  LD   Disp3(Rm4), Rn4   
      1ddd-nnnn-mmmm-0110  SD   Disp3(Rm4), Rn4   
      
      00dn-nnnn-dddd-1000  LW   Disp5(SP), Rn5   
      01dn-nnnn-dddd-1000  LD   Disp5(SP), Rn5   
      10dn-nnnn-dddd-1000  SW   Disp5(SP), Rn5   
      11dn-nnnn-dddd-1000  SD   Disp5(SP), Rn5   
      
      ...   
      
   Avoid temptation to make immediate and displacement fields overly large,   
   as for small values these tend to have a very rapid drop-off. Not enough   
   registers hurts more here than narrow Imm/Disp fields.   
      
   Main place a larger Disp is justified is for SP-rel Load/Store.   
      
   The 16-bit ops don't need to be sufficient to support the whole ISA,   
   merely to provide space-savings for a subset of common-case operations.   
   Preferably with the encodings not being confetti.   
      
      
      
   32 bit instruction layout could do whatever.   
      zzzz-oooo-oomm-mmmm-zzzz-nnnn-nnyy-yyy1  //Similar to XG3   
      zzzz-zzzo-oooo-mmmm-mzzz-nnnn-nyyy-yyy1  //Similar to RISC-V   
      zzzz-zzoo-ooom-mmmm-zzzz-znnn-nnyy-yyy1  //Intermediate, 5b registers   
      ...   
      
   May make sense to slightly shrink immediate and displacement fields   
   slightly relative to RISC-V, and instead assume use of jumbo prefixes.   
      
   Also, probably not doing something like RISC-V's JAL, which is an   
   unreasonable waste of encoding space.   
      
   As for 5 or 6 bit registers, possibilities:   
   * Purely 5-bit, like traditional RISC-V   
   * Purely 6 bit, like XG3, but this leaves less encoding space.   
   * Mixed 5 or 6 bit, like XG1, but more intentionally   
   ** In XG1, the subset of 32b ops with Reg6 were a bit of a hack.   
      
      
   Possible, assuming a mixed 5/6 bit scheme:   
      zzzz-oooo-oomm-mmmm-zzzz-nnnn-nnyy-yyy1  //3R, Reg6   
      zzzz-zooo-oozm-mmmm-zzzz-znnn-nnyy-yyy1  //3R, Reg5   
      iiii-iiii-iimm-mmmm-zzzz-nnnn-nnyy-yyy1  //3RI, Reg6 (Imm10)   
      iiii-iiii-iizm-mmmm-zzzz-znnn-nnyy-yyy1  //3RI, Reg5 (Imm10)   
      iiii-iiii-iiii-iiii-zzzz-nnnn-nnyy-yyy1  //2RI, Reg6 (Imm16)   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)