From: terje.mathisen@nospicedham.tmsw.no   
      
   In my original encoder I had slightly different priorities, in the   
   following order:   
      
   a) The least possible use of selv-modifying code (I ended up with a   
   single two-byte Jcc  instruction).   
      
   b) All instruction bytes (except for that SMC branch) taken from the   
   MIME transparent set: This is effectively the 65 Base64 chars plus a   
   couple more for a total of around 70-72. I.e. these chars were   
   guaranteed to be able to pass through all email gateways, including via   
   IBM EBCDIC and back to ASCII.   
      
   c) The ability to tolerate as much reformatting as possible, including   
   replacing the original CRLF line endings by any 0,1 or 2 white space or   
   control chars.   
      
   d) Smallest possible size.   
      
   Terje   
      
   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   
   > 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   
   > sequence like this too long?  The SHL and RCR could also probably be   
   > replaced with branch JC and XOR 80h.   
   >   
   > This is 32-bit code, correct?  Has anyone looked at using AAM 10h (16)   
   > 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,   
   > perhaps, XOR or SUB the values together would create a larger range?   
   >   
   > Or, maybe, AAM could be used to reduce the wasted bits for 2:1 XOR SUB   
   > SUB?  I.e., use smaller values?   
   >   
   >   
   > Rod Pemberton   
   >   
      
      
   --   
   -    
   "almost all programming can be viewed as an exercise in caching"   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)