> >2. I've added some GNU C machine code templates and guarded 'em with
> >#ifdef(__GNUC__).
>
> That would be in the #ifndef SHA1_ASM section.
Why??? It's just a macro! It doesn't hurt anybody if you never refer to
it...
> I'm not sure I like that.
Well, if #ifdef(WIN32) (which is actually *wrong* as it should sound as
#ifdef(MSC) or similar) is OK, then what's wrong with #ifdef(__GNUC__)?
:-)
> I would prefer if you could come up with a Power PC assembler
> version of the entire sha1_block function.
And benefit what? I used to consider assembler implementation only if
there're some hardware gadgets one can't address from C (e.g.
carry-bits, 128 bit multiplication/division on MIPS R[4,5,8,10,12]000,
SPARCv9 instructions:-) or compiler doesn't do good job on register
allocation (which is usually case for Intel). Then I used to multiply
this by expected performance improvement.
Now PowerPC has a handful of registers and I don't believe *anybody*
will do better job allocating registers than compiler. Then keep in mind
that different PowerPC OSes seem to use different calling conventions (I
myself don't have like crystal-sharp clue, but doesn't AIX calling
convention differs from one in Solaris/Linux?) and you'll have to cope
even with this. Well, I might be wrong about this as it's just someting
I vagely remember since 1995...
And what do we have on the other hand? As you see I can *trivially*
reach rotate instruction with a GNU C extension and benefit in
performance *all* I possibly could if I hand-code it (as compiler
obviously does good enough job allocating registers and scheduling
instructions). In addition I'm excused from coping with ABI details. So
why not put an extra line instead of spending a lot of time "assembling"
it? Yes, it's probably not fair against those who use IBM compiler, but
who said it should be:-) And IBM in turn might offer some extensions as
well and someone has to dig into a manual. If latter isn't the case one
can always generate .s file with GNU C and simply include it into the
distribution. It definitely doesn't feel like anybody has to come up
with anything better than that... Simply because it won't be *damn*
better.
Andy.
P.S. As I've already mentioned (several times) I'm looking at MD5 now. I
see it's *very* similar to SHA and I'm thinking about putting
*_Update-*_Final functions into a common .h file that could be simply
included with different initial #defines from [md5,sha,sha1]_dgst.c
files. Good/bad idea? If good, what's the best spot for such file?
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
