> > I was just about to suggest to rename solaris-sparc-cc to
> > solaris-sparc-sc3 and solaris-*-sc4 to solaris-*-cc which would cover
> > both SC4.x and SC5.x... But I can see you've introduced sc5 option:-(
>
> I would also prefer to have only one entry. But how would you
> handle the SC4 optimizer bug that makes the bignum library dump
> core if there is only one entry for SC4 and SC5?
I wouldn't... The comment was rather an expression of grief than and an
actual suggestion. That's why I've ended it with ":-(" :-)
>
> > In either case I don't find my v8plus implementation of bn_asm.c in
> > solaris-usparc-* lines. How come?
>
> I thought you were still working on something in the v8plus code.
Not really. At some point I said "v8plus code is fine even for v9." Then
I said "I'm wrong, v8plus is no good for v9, I'll look at v9." By latter
I didn't mean that v8plus needs extra work. Finally I said "I won't do
v9 as it doesn't look like I'll be able to beat SC5.0 by at least 15%."
In either case, I see it's already there... This brings us to the
solaris-usparc-gcc question:-) Shall you have one? Basically it's very
same as solaris-sparc-gcc, but with -mcpu=ultrasparc instead of -mv8 and
asm/sparcv8plus.o. Yes, I know you had problems with gas, but anyway...
And finally how about solaris64-usparc-sc5? Someting in following style:
"solaris64-usparc-sc5","cc:-xtarget=ultra -xarch=v9 -xstrconst -xO5
-xdepend -Xa -DB_ENDIAN:-D_REENTRANT:-lsocket -lnsl:SIXTY_FOUR_BIT_LONG
RC4_CHAR DES_INT DES_PTR DES_RISC1 DES_UNROLL BF_PTR:::",
I know I promised to go through all the options, but it's a working
setup... My idea of "going through the options" was more for performance
sake:-)
Andy.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
