From: james.harris.1@nospicedham.gmail.com   
      
   On 19/07/2017 09:10, Kerr Mudd-John wrote:   
   > James Harris  wrote in news:okm0bq   
   > $4vd$1@dont-email.me:   
   >   
   >> On 18/07/2017 22:34, James Harris wrote:   
   >>> On 18/07/2017 19:34, Kerr Mudd-John wrote:   
   >>>> "wolfgang kern"  wrote in news:oklfc9$1lr5$1   
   >>>> @gioia.aioe.org:   
   >>>>   
   >>>>>   
   >>>>> James Harris asked:   
   >>>>>   
   >>>>>> How short was the (current) shortest solution?   
   >>>>>   
   >>>>> by adopting Kerr Mudd-John's decoder routine we are down to 209 byte   
   >>>>> yet.   
   >>>>> __   
   >>>>> wolfgang   
   >>>>>   
   >>>>   
   >>>> Depends on the spec; my shortest using only B64 chars is 246.   
   >>>   
   >>> OK. Whether 209 or 246 it's a substantial bit of code to write in   
   >>> printable characters!   
   >>   
   >> On the size, has anyone looked at writing a normal base64 decoder,   
   >> encoding it in a form which is easy to decode, and decoding it first.   
   > By   
   >> that I mean that at present I gather the source "text" will have the   
   >> following   
   >>   
   > SMC:   
   >>        
   >>   
   >> And I wonder if it would be shorter to change that to   
   >>   
   > 2:1:   
   >>        
   >>   
   >> The pre-decoder would convert just the base64 decoder to binary. The   
   >> binary version of the base64 decoder would then decode the text. The   
   >> pre-decoder would decode a simple format.   
   >>   
   > You might try running e.g. (246 byte 2:1)   
   >   
   > ZRPRhp0XPR5p1PRRjL4hPa5LU1GJ1GLUX+G=1GeRSVG8+r6238wbt083t+RU=rY=   
   > 66Z2202Zffffff0222F6====MJ=20=17===eeee+++slOBI9UnEdoAasbaANE9E7   
   > jelperHQE9sAjesuH8lpssMIG7asA9babaaGv7h8A7IdH9RKi8A9EGI8sCoAlpin   
   > MIT9lpadITt7YoH9f7=tAm6CAHNIcNIZWxsbyB3b3JsZCEk=   
   >   
   >   
   > through debug.   
   >   
   >> On one hand, the base64 decoder might take up more room. On the other   
   > it   
   >> could use any asm instructions so might be shorter. (Some or all of the   
   >> pad could be saved, too.)   
   >>   
   >>   
   >   
   > These wheels have already been invented!   
      
   Cool. That's what I was asking. No point spending time thinking about   
   what others have already worked through.   
      
   One more "wheel", though, just out of interest. I see that of the   
   opcodes available there are, in hex, these "ranges":   
      
   the 3x range which gives some very useful xor and cmp   
   the 7x range which provides short jumps _if_ offsets fit   
      
   but there are not many useful instructions available. Has it already   
   been looked at to xor a run of bytes in order to make some other opcode   
   ranges available (and maybe make jCC offsets more amenable)? I've not   
   worked out any particular xor value. Just asking if it's already been   
   considered.   
      
   > - I know there's a lot of posts   
   > to read but they're all there.   
      
   There are certainly many of them!   
      
   > The first describes what we (Wolfgang and   
   > I anyway) call the SMC version; the latter the 2:1 version. (possibly   
   > other primary decoders are possible; we didn't get very far from Terje's   
   > "xor sub sub")   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)