From: admin@nospicedham.127.0.0.1   
      
   On Tue, 13 Jun 2017 14:31:52 +0100, Rod Pemberton  wrote:   
      
   > On Tue, 13 Jun 2017 11:19:31 +0100   
   > "Kerr Mudd-John"  wrote:   
   >   
   >> On Thu, 08 Jun 2017 11:46:45 +0100, Terje Mathisen   
   >>  wrote:   
   >   
   >> > Guys, I would love to see you come up with a better 2:1 encoding   
   >> > algorithm instead of the current micro-tweaking of the one I came   
   >> > up with!   
   >> >   
   >> > There has to be more than one way to achieve full byte coverage,   
   >> > XOR-SUB-SUB was more or less the first thing I came up with. :-)   
   >> >   
   >>   
   >> I think I might save 4 bytes with a (shl (A xor B),1) xor B decoder,   
   >> but I'm uncertain (the jmpback address goes to an invalid 5F from 61   
   >> and the other 2 are in the 2B buffer anyhow) and it seems a lot of   
   >> effort to create a whole new encoding table just for that.   
   >>   
   > ...   
   >   
   >> I'd need a reasonable range of opcodes; might as well go for a full   
   >> coverage.   
   >>   
   >> 2:1 is quite wasteful (7+7=14 bits->8; wastes 6/16=0.375)  I've been   
   >> toying with a 3:2 (7+7+7=21->16 wastes 7/24=0.29166.), but can't see   
   >> a simple algorithm.   
   >   
   > If you have 7 bytes (8-bit), can't you just store the MSB for the 7   
   > bytes in one 7-bit character?  You'd have 7 characters with the lower   
   > 7-bits of an 8-bit byte, and one character with the upper bits. AFAICT,   
   > that would require two SHL and an RCR to implement.  One SHL on the   
      
   Hmm, the current stage2 decoder is 58 bytes (encoded at 2:1 this takes up 116)   
   so we'd be looking at rounding that to 63; == 7*9+9hibit bytes=72: so   
   116-72=44 bytes to get our decoder into to come out ahead.   
      
   Sounds good but each pair of non-B64 opcodes costs [2 holding bytes +2 for a   
   slide +3 to xor it on +5/6 to set ax] = 12/13.   
      
   > packed upper bits value to move the bit into the CF, and a SHL and RCR   
   > on the 7-bit value to fill the MSB with the CF.  Is an instruction   
      
   I like the thinking; not sure it's do-able.   
      
   > sequence like this too long?  The SHL and RCR could also probably be   
   > replaced with branch JC and XOR 80h.   
      
   It's not the length of code reqd "percy"; it's more a problem with the number   
   of fixups to get these opcodes (which *then* causes longer code!).   
      
   > This is 32-bit code, correct?  Has anyone looked at using AAM 10h (16)   
   oldskool: 16bit.   
   > with XLAT?  AAM would allow you to break a 7-bit character into   
   > upper 3-bits and lower 4-bits, etc.  You could then use XLAT to convert   
   > one or both of them into another, larger value, up to 8-bits.  Then,   
      
   to 7bit maybe:   
      
   > perhaps, XOR or SUB the values together would create a larger range?   
      
   the XLAT table takes up a chunk of space, and can only XLAT to B64, unless   
   more code is put in to set it up.   
      
   > Or, maybe, AAM could be used to reduce the wasted bits for 2:1 XOR SUB   
   > SUB?  I.e., use smaller values?   
   >   
   AAM is 0xD4 0x10; fixup reqd.   
      
      
   >   
   > Rod Pemberton   
      
      
   --   
   Bah, and indeed, Humbug   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)