From: quadibloc@invalid.invalid   
      
   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?   
      
   John Savard   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)