> > > #if !defined(BF_PTR) && !defined(BF_PTR2)
> > > #define BF_PTR
> > > #endif
> > i.e. the comment is effectively *disregarded*, isn't it?
>
> This is autogenerated in Configure.
Oops! I suppose I owe an apology for my comment following the quoted
string then. I apologize and I'm sorry!
BUT! Even after I've slept it over I can't confirm that observations
made were false. The BF_PTR code *does* depend on the long being 32 bits
wide, which I still consider as a unacceptable programming practice and
a bug. It was worked around for IRIX64 by introducing #ifdef(__sgi)
(which is by the way MIPSpro specific, i.e. gcc won't catch on) but no
serious consideration was actually taken. Moreover!!! Feeling little
guilt I've compiled together following table this morning. Numbers are
microseconds (i.e. less is *better*) for set_key/ecb_enc generated by
crypto/bf/bfspeed test program.
On Alpha EV4, 233MHz, Linux 2.2.6, libc-2.0.7, egcs-1.0.2
BF_LONG #define BF_PTR #undef BF_PTR
long (64 bits) 9190/16.7 931/1.65
int (32 bits) 887/1.63 755/1.39
On UltraSPARC-2i, 300MHz, Solaris 7/64, SC5.0
BF_LONG #define BF_PTR #undef BF_PTR
long (64 bits) BUS ERROR 650/1.15
int (32 bits) 359/0.625 599/1.09
As you see narrowing BF_LONG to 32 bits does *not* have bad impact on
performance, but a good one and it looks like in first hand on Alpha!
And why shouldn't it? The cache is used better as none of it is wasted.
I find 20% improvement on Alpha rather impressive. Though it might be
GNU C specific. I mean Digital's compiler would probably exhibit
difference closer to Ultra case...
Bottom line. "#define BF_LONG unsigned int" still makes perfect sense on
all (well, at least on mentioned:-) platforms. #undef BF_PTR is still
best choice for Alpha (presumably because s[48]addq instruction gets
hired to do the job). SPARC users should keep sticking to #define
BF_PTR.
>
> I am making if #ifdef WIN16 for now.
Wouldn't e.g. #ifdef LP64, #ifdef ILP32, #ifdef LP32 be a better choice?
On the other hand! Does the library actually *compile* under
MS-DOS/WIN16? Does *anybody* actually use it? If some previous (SSLeay)
version was compiled once upon a time, I don't think it means a lot now.
Just think about this particular case... The way I see it the code (at
least parts of it, like bn assembler stuff for none-Intel and this LP64
woes) is out of control. My point is that it's better/safer to say "32
bits architecture is a requirement" than to give a false impression.
Cheers. Andy.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
