Hi!
I've got a response on the subject from <[EMAIL PROTECTED]>. As it's
obviously not possible to reply to the adress, I'll reply to the list...
> > ! #define INIT_DATA_h0 0x67452301UL
>
> Is the "UL" portable (ie required by the ANSI spec)?
Yes, UL is ANSI compliant modifier.
> Personally I would do "((unsigned long)0x67452301)".
Should do as well...
>
> If changing everything back to 32-bit code speeds up the 64-bit platforms
> fine. But I don't understand why Eric would have gone to all the trouble
> of implementing 64-bit.
You're missing the point! And the point is that it looks like *no*
*real* attempt to make the code 64 bit safe was actually made. I've
examined SHA code on Alpha today (actually for the first time to be
honest, because I got really curious how the hell does it work when it's
not supposed to:-) and figured out that it worked for sole reason that
L_ENDIAN was not defined on Alpha. Latter means that all those 32 bit
dependencies I've pointed out in my first post were #ifdefed away...
I.e. it was sheer luck that the code actually worked! It would break the
moment someone would put -DL_ENDIAN into compiler command line for
Alpha. Why would anybody? I don't know... Alpha is little endian to
start with. Then someone whould contribute some code that would happen
to be dependent on L_ENDIAN defintion... But in either case is it a good
idea to put a code in that depends on sizeof(long) being 4? Definitely
not!
> Is it the case that it was once done right and was
> faster, but later got broken?
It looks like you're talking about Blowfish, because as there is no
benchmark program accompanying SHA code I don't beleive *anybody* ever
instrumented it. And if you do talk about Blowfish, then check out my
latest post on the matter ("Re: LP64: blowfish woes" subject). Just one
extra comment to it. #undef BF_PTR version of BF_ENC macro isn't in any
way 64 bit specific and even works 20% faster with BF_LONG=int on Alpha.
> If so it'd be nice to salvage the faster
> code by fixing the ifdefs rather than throwing away Eric's work. 64-bit
> systems are going to be the norm soon.
>
> The other angle that comes to mind is if there are machines where "unsigned
> int" is 64 bits. Seems like Cray's are that way.
Well, I had never chance to work on Cray so I wouln't know. But I'll
keep it mind... But if you (or anybody else) have access to Cray, could
you examine cc manual page for presence of any command line option that
lets you *choose* sizeof(int)? It might also be useful to keep in
mind:-)
> Will the code still work on such a machine?
SHA? *NO*! Well, to be accurate as long as nor L_ENDIAN or B_ENDIAN are
defined (which again should be considered as *bug* and be fixed).
Blowfish? #undef BR_PTR variant would work.
>
> Great work on getting this asm stuff and performance straightened out. It's
> really needed and no one else showed interest. Thanks.
Well, thank you! It would be nice to know who I just thanked:-)
Cheers. Andy.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
