On December 2, 2003 05:19 am, Richard Levitte - VMS Whacker wrote: > geoff> I understand the desire to cater for CPU pipelining with the > geoff> 8-wise loop unrolling, but is this a better solution than just > geoff> using memset() and letting the compiler take care of the same > geoff> sort of thing? > > There are several such loops. One is the one you're talking about, > but you should also look in bn_expand_internal().
Yes I've since seen been through all of bn_lib.c and a smattering of revulsion was unavoidable. > I have no personal problems with switching to using memset() and > memcpy() (for bn_expand_internal()), unless a function call gives an > unacceptable overhead. Well I'd like to get Andy's call on this before changing anything. What comments there are in the source are his, so I must assume that he's seen reason to use these inline alternatives. Andy - what if we switch to mem[set|cpy] alternatives by default, and preprocess to in the inlined versions if BN_MEM_INLINE (or somesuch) is defined? This way, architectures (or compilers) that show a benefit with your unrolled versions over what the compiler generates can enable this on a case by case basis? In fact, the logical thing (imho) would be to define openssl-wide macro equivalents to memset(,0,) and memcpy and use those consistently everywhere (ie. without #if statements all over the place). That way, your inlined alternatives, if they are benefitial in certain circumstances, could be applied globally. Thoughts? > If we switch to use the mem* variant in bn_expand_internal(), it needs > to be corrected. The current form is unbelievingly buggy (I didn't > even look at it last I played around with this code, since it was > disabled). Well, I can see that the memset() is excessive considering that b->top words of that same range are immediately overwritten afterwards by the memcpy(), and likewise the use of sizeof(b->d[0]) seems strange given the logic in the previous line uses sizeof(BN_ULONG) (which is better). But "unbelievably buggy"? How so? (In fact, the one recurring "bug" to me is the continual use of (words+1) when the caller has clearly expressed an interest in (words) instead ... another thing to look into at another time - and please don't mess with this in the mean time, I've got too many diffs lying round already and this could upset my audit apple-cart :-) Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
