From: nowhere@never.at   
      
   Kerr-Mudd,John wrote:   
   [..]   
   >>> B64 216 bytes, ll63   
   >>> ZRRj=hZhXP5ZiPRR4wPj9aSH5q+1GuA0O+0O80g387z9F84uC07pIu=Sajq0fa=   
   >>> 660FW0Fv4r0Fg0Ft1FbhghX1FH1FJ1FN1FU0FX0fe0Fp0G34g666eeee   
   >>> h=+hr5==ht2=ahreDaDAyjlE=3hwapNcAHHAA666L/40MGVOQX4o4gudOPYPqM   
   >>> tAm6CAHNIcNIZWxsbyB3b3JsZCEk=   
      
   >> very good, and now you confirmed that SMC may be shorter than 2:1,   
   >> and it's already pretty close to 214(209)! :)   
      
   >> is there any reason for the two first lines show different size ?   
   >> I mean other than visual separation of blocks.   
      
   > Yes, I was unable to fit in an "ignore crlf" step earlier; I need the   
   > B64decoder to be contiguous.   
      
   Me too tried such help before the 214/209 variants.   
   I missed that you dont check for and skip <2B anymore.   
      
   >> It works here but it may not work on other machines because you modify   
   >> 012b,0133,0138 within the same cache-line without a branch.   
      
   > I see; the first branch FU is dodgy; but the flow should always take the   
   > 2nd branch 1st time, so that should refresh the cache for the 2nd and 3rd   
   > FU AIUI.   
      
   Ok, I saw your first branch would work as 012a 70 39  jpe 0165 (12c+39)   
   in the woods except for an odd parity result of cmp [bx],dh, and as CMP   
   act like a SUB: I see now 05a-068 = F2 == 5 bits ON == odd parity, so OK.   
   I use JNC after XOR which branches always for a first branch after SMC.   
      
   >> I can't catch why: 012a  jpe +7 ;wouldn't jz +7 do it as well ?   
   > Because the value at bx (5A=pop dx) isn't zero?   
      
   mmh..? cmp [bx],dh [to see your first "h"] will produce Z(equal) or NZ.   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)