> >> O.K. Then I propose deleting (rather then recreating) all those
> >> automatically generated assembler versions, with appropriate changes
> >> to the configuration script.
>
> > i don't get it! has anybody read my posts? does it get through at all?
> > well, it must, because i myself get my messages echoed back from the
> > list...
>
Wow! It works, it works...
> For the general case (everything except *-usparc-*), your proposal
> amounted to just that, didn't it?
Yes and no. "Yes" for personally me as I don't plan to run any
"production" on SPARC v8 and don't have much spare time (who does?).
"No" for OpenSSL as they're the "Nice Guys who do The Right Thing[TM]"
and think for *everybody's* good:-) I did mention that it's *worth*
incorporating my assembler implementation of bn_*_comba[48] (*and*
eight-lines bn_div_words exploiting hardware division:-). Or didn't
I...? Anyway! Naturally there're two ways solve this puzzle.
One way is to have bn_asm.c carry bn_functions *other than*
bn_*_comba[48] and have sparc.s carry bn_*_comba[48] (*and*
bn_div_words:-). In this case you'd have to introduce a new macro, e.g.
COMBO48_ASM, and #ifdef corresponfing functions from bn_asm.c.
Another way is to *append* my bn_*_combo[48] assembler implementations
to the *current* sparc.s (with minor changes like new eigth-lines
bn_div_words:-) and leave config and .c files as is (i.e. no new macros
nor new #ifdef spaghettis).
It's up to you to choose... Well, I realize that it's just *my* idea of
"The Right Thing[TM]" and you're free to choose to drop sparc.s as you
were intended...
>
> Your proposed changed line for Configure is probably not meant
> literally, though (even after removing the extra line-breaks
> introduced by your text-editor or mail software :-):
>
> "solaris-sparc-sc4","cc:-xarch=v8 -xstrconst -xO5 -xdepend -Xa -DB_ENDIAN
>-DBN_DIV2W:-lsocket -lnsl:\
> BN_LLONG RC4_CHAR DES_PTR DES_RISC1 DES_UNROLL BF_PTR:asm/sparc.o::",
>
> asm/sparc.o is a file that you do _not_ want to use in that case,
Well, I ran './Configure solaris-sparc-sc4 no_asm' that disregards
asm/sparc.o. After all it's the *only* way to have it built *anyway*,
isn't it?
> if I
> understand you correctly, because the -xarch=v8 option allows us to
> use bn_am.c for sc4 without performance problems. Correct?
Yes, this is correct. I.e. -xarch=v8 brings us up to solaris-sparc-gcc
level and effectively obsoletes asm/sparc.s in its *present* state.
>
> Your new assembler implementation for the usparc cases I have not
> tested yet. Obviously it still needs to be integrated in the
> Configure/Makefile mechanisms. So we'd need a new configuration
> variant "solaris-usparc-gcc", right?
Absolutely!
Cheers. Andy.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
