> Has anyone done any work on the asm for the PPC platform?
The question to be posed and answered first should be "is it worth the
effort?" The catch is that in cases when compiler provides means for
reaching out for full functionality of underlying hardware it's very
hard to do noticeably better job hand coding the same thing in
assembler. I mean it's almost certainly possible to do better job, but
not *noticeably* (say +30% performance improvement) better which makes
it hard to justify the effort. Now the next question (naturally) is does
*your* compiler provide such means and (more important) are you actually
using them?
> localhost> openssl version -a
> OpenSSL 0.9.6a-beta3 30 Mar 2001
> built on: Wed Apr 4 13:12:36 EDT 2001
> platform: Darwin
> options: bn(32,32)
^^ And the answer has to be "you're not using your
compiler's potential".
> Any tips?
Run 'apps/openssl speed' and save output. Then reconfigure with
'./Configure rhapsody-ppc-cc -DTIMES -DNO_GMTIME_R' (or something),
recompile and rerun 'apps/openssl speed'. You should notice improvement.
What's the difference? rhapsody-ppc-cc line instructs the compiler to
use 64-bit "long long" type which should reduce the amount of
multiplications by factor of 2 (in this case). What's next? One (well, I
can do it if you want me to) should analyze the assembler output for
bn_asm.c in order to figure out if compiler does some obviously dumb
things (like not using mulhwu instruction). If it doesn't (the way I
remember it I found the quality of code generated by "Rhapsody" compiler
fair), then we can be pretty sure that hand coding in assembler won't
pay off, make sure ./config picks BN_LLONG for the platform in question
and dismiss this case. If it does, then we should first figure out if we
can give it a hand with some inline assembler directives...
Andy.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
