home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.asm.x86      Ahh, the lost art of x86 assembly      4,675 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 3,378 of 4,675   
   wolfgang kern to All   
   Re: Reciprocal MUL LUT   
   27 Apr 18 13:46:05   
   
   From: nowhere@never.at   
      
   Thanks Terje,   
      
   >> I'm looking at the possibility of just calculating these on the fly:   
      
   >> Use either the SSE reciprocal estimator or a FP division to get a   
   >> starting approximation, then use a NR iteration to double the number   
   >> of bits each round.   
      
   >> When you get past 64 bits you have to start working with 128, then   
   >> 256 and 512 bit values using multiple 64-bit chunks, but it should   
   >> still be relatively fast.   
      
   > OK, I've done the math:   
   >   
   > If you start with a SSE reciprocal lookup you get a fp number with ~12   
   > signficant bits = app_1_over_n.   
   >   
   > You then run one iteration with 32-bit float:   
   >   
   >  prod = n * app_1_over_n;   // This value will be close to 1!   
   >   
   >  adjust = 2 - prod; // Close to 1.0   
   >   
   >  app_1_over_n *= adjust; // Approximately 24 bits accurate   
   >   
   > For the next iteration we switch to double and do the same:   
   >   
   >  app_1_over_n_d = (double) app_1_over_n;   
   >   
   >  prod_d = n * app_1_over_n_d;   
   >   
   >  adjust_d = 2 - prod_d;   
   >   
   >  app_1_over_n_d *= adjust; // Approximately 48 bits accurate   
   >   
   > (Up to now we have used about 20 cycles, so a chip with a fast divider   
   > could possibly give us 53 bits in about the same time.)   
   >   
   > At this point we switch to integer code only and run one iteration with   
   > 64-bit values resulting in nearly 64-bit accurate values.   
   >   
   > For the rest we run a slightly different NR iteration:   
   >   
   >   adj = 1 - n*approx;   
   >   approx += adj*approx;   
   >   
   > We only need 64 bits for the adjustment factor since it will be close to   
   > zero, the adj*approx product gives us 128 bits to add to the 64-bit   
   > approx value and we still double the precision.   
   >   
   > The same way we can work with 128-bit numbers for almost the entire   
   > 256-bit stage and 256-bit numbers for the 512-bit.   
      
   I'll check if such a multistage NR doesn't show any rounding issues,   
   which I was/am afraid of.   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca