> Log: > Unobtrusive backport of 32-bit x86 Montgomery improvements from 0.9.9-dev: > you need to use "enable-montasm" to see a difference. (Huge speed > advantage, but BN_MONT_CTX is not binary compatible, so this can't be > enabled by default in the 0.9.8 branch.) > > Index: openssl/CHANGES > ============================================================================ > $ cvs diff -u -r1.1238.2.94 -r1.1238.2.95 CHANGES > --- openssl/CHANGES 30 Apr 2008 16:11:31 -0000 1.1238.2.94 > +++ openssl/CHANGES 1 May 2008 23:11:30 -0000 1.1238.2.95 > @@ -4,6 +4,28 @@ > > Changes between 0.9.8g and 0.9.8h [xx XXX xxxx] > > + *) Partial backport from 0.9.9-dev: > + > + New candidate for BIGNUM assembler implementation, bn_mul_mont, > + dedicated Montgomery multiplication procedure, is introduced. > + While 0.9.9-dev has assembler for various architectures, here > + in the 0.9.8 branch, only x86_64 is available by default. > + > + With Configure option "enable-montasm" (which exists only for > + this backport), the 32-bit x86 assembler implementation can be > + activated at compile-time. In 0.9.9-dev, BN_MONT_CTX is modified > + to allow bn_mul_mont to reach for higher "64-bit" performance on > + certain 32-bit targets. With "enable-montasm", this BN_MONT_CTX > + change is activated in the 0.9.8 branch. > + > + Warning: Using "enable-montasm" thus means losing binary > + compatibility between patchlevels! (I.e., applications will > + have to be recompiled to match the particular library.) > + So you may want to avoid this setting for shared libraries. > + Use at your own risk.
The keyword is "certain." While some platforms do require binary incompatible changes, others do *not*. x86 does *not*, so there is no reason to modify bn.h in this case. As for *now* the only platform that depends on bn.h update is 32-bit UltraSPARC build (though for 64-bit build one would have to adapt sparcv9a-mont.pl), but PowerPC and Itanium are to join. > +#if defined(MONT_WORD) && defined(OPENSSL_BN_ASM_MONT) && (BN_BITS2<=32) > + if (!BN_from_montgomery_word(r,tmp,mont)) goto err; > +#else > if (!BN_from_montgomery(r,tmp,mont,ctx)) goto err; > +#endif For reference, BN_from_montgomery_word was introduced for performance (it eliminates redundant malloc, which gives measurable improvement), there is no reason to make it BN_BITS2<=32... I mean it should be there on not be there at all. The reason it was not back-ported with x86_64 module was that the minor releases are not widely tested by community (at least we don't explicitly encourage it prior minor releases) and we formally don't know if code breaks on some platform team members don't use on regular basis. x86-mont.pl was not back-ported for approximately same reason. Trouble is that while on x86_64 we have to cope with limited number of assemblers (fairly recent GNU and Solaris ones, both were explicitly tested by me), it's not the case on x86 platforms, where we find GNU, nasm and few vendor assemblers of all ages. One can argue that I'm being conservative, but isn't it what -stable branch should be about? Bottom line. x86-mont.pl can be added to 0.9.8 with only Configure and Makefile modifications and I think that's how it should be done. Whether or not it should be conditional. One can argue that sse2-capable GNU assembler qualifies as fairly recent and therefore fairly tested configuration and therefore exclude it from no-sse2 builds. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
