SHA-256/-512 x86_64 assembler
SHA-256/-512 x86_64 assembler implementation is available in HEAD now. As usual, code was benchmarked on Opteron only and out of curiosity I'd like to hear from people with EM64T hardware. The test it grab latest openssl-SNAP-* at ftp://ftp.openssl.org/snapshot/ and './config no-asm; make; apps/openssl speed sha' and then './config; make; apps/openssl speed sha'. For reference, the commentary section contains following note: # Special note on Intel EM64T. While Opteron CPU exhibits perfect # perfromance ratio of 1.5 between 64- and 32-bit flavors [see above], # [currently available] EM64T CPUs apparently are far from it. 64-bit # version, sha512_block, is hardly faster than 32-bit one. This is # presumably because 64-bit shifts/rotates apparently are not atomic # instructions, but implemented in microcode. This is actually based on benchmark results obtained for C version, but I see no reason why it wouldn't hold true for assembler implementation. A lot of thanks in advance. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [Fwd: Re: [openssl.org #1171] Unable to pass make test 2]
Original Message
Subject: Re: [openssl.org #1171] Unable to pass make test 2
Date: Mon, 25 Jul 2005 00:39:36 +0200 (METDST)
From: Andy Polyakov via RT [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: openssl-dev@openssl.org
test BN_sqr
make[2]: *** [test_bn] Error 139
Could you examine
https://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=1146 and see if
you confirm that it's identical problem. A.
I am sorry but I cannot reproduce the problem any more. I did these steps after
reporting the problem till now:
- instaled openssl 0.9.7g instead of 0.9.7e and relinked lib{crypto,ssl}.so and
dtto.so.0 to this version,
- instaled openssh 4.1 instead of 4.0,
- instaled latest binutils,
- and instaled gcc 3.4.4.
And now it (make make test for openssl 0.9.8) works fine.
Regards,
marcel Svitalský
--
**
tlf: (+420) 245 005 546 ... po-pá 8:00-16:30
tlf: (+420) 606 439 651
e-mail: [EMAIL PROTECTED]
e-mail: [EMAIL PROTECTED]
Nebojte se ¹ifrování - ¹ifra je jako obálka na dopise.
Osobní a dùvìrné vìci také nepí¹ete na pohlednici.
GPG public key (ID 0xD98EC83A) fingerprint:
3BEB 4658 A998 B9B3 3476 AD64 EF87 D0A5 D98E C83A
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: mk1mf.pl doesn't generate makefile for Windows CE
I've chosen to unify VC-32.pl and VC-CE.pl instead. I mean VC-CE.pl is gone now and VC-32.pl is expected to take care of all Windows flavors, Win32, Win64 and WinCE. See http://cvs.openssl.org/chngview?cn=14275 for reference. I see. I downloaded the latest 0.9.8-snapshot, and it generates correct cedll.mak. I've been browsing through MSDN and didn't quite figured out where _WIN32_WCE and platform-specific pre-processor macros get assigned/defined. Most notably I used to believe that they're pre-defined by compiler driver itself, but [this time?] I failed to find an explicit reference confirming that this is actually case. I found reference that at least _WIN32_WCE is defined through project preferences as -D_WIN32_WCE=$(CEVersion). Now, VC-32.pl passes down $(WCETARGETDEFS), but does it actually cover _WIN32_WCE? Can you double-check this? Or better yet, can you post how WCETARGETDEFS is [normally] expanded? Just in case, there is ongoing discussion about improving CE support, which goes under OpenSSL for Windows Mobile 2003 subject, see for example http://marc.theaimsgroup.com/?t=11218523281r=1w=2. I feel changing too many things at once is not a good idea. How about making the current code to compile on the corrent supported platforms first, then making changes for other platforms such as eVC4 + PPC2003SDK if needed. After that, remove dependencies on wcecompat for platforms which allow that. Well, the way I feel is that currently supported platforms needs definition first:-) And once again [as already mentioned in above mentioned thread] I still fail to see why PPC2003 needs special treatment. I'd rather classify them by _WIN32_WCE value or something similar. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [Fwd: Re: [openssl.org #1171] Unable to pass make test 2]
test BN_sqr
make[2]: *** [test_bn] Error 139
Could you examine
https://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=1146 and see if
you confirm that it's identical problem.
I am sorry but I cannot reproduce the problem any more. I did these steps
after
reporting the problem till now:
- instaled openssl 0.9.7g instead of 0.9.7e and relinked lib{crypto,ssl}.so
and
dtto.so.0 to this version,
- instaled openssh 4.1 instead of 4.0,
- instaled latest binutils,
- and instaled gcc 3.4.4.
And now it (make make test for openssl 0.9.8) works fine.
Working theory in #1146 is that it's a bug in binutils, either linker or
assembler. And the fact that binutils update helped in your case does
not refute it, on the contrary confirms. Can you tell wich binutils
version did you upgrade from? And which version to? A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [Fwd: Re: [openssl.org #1171] Unable to pass make test 2]
Andy Polyakov via RT wrote:
test BN_sqr
make[2]: *** [test_bn] Error 139
Could you examine
https://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=1146 and see if
you confirm that it's identical problem.
I am sorry but I cannot reproduce the problem any more. I did these steps
after
reporting the problem till now:
- instaled openssl 0.9.7g instead of 0.9.7e and relinked lib{crypto,ssl}.so
and
dtto.so.0 to this version,
- instaled openssh 4.1 instead of 4.0,
- instaled latest binutils,
- and instaled gcc 3.4.4.
And now it (make make test for openssl 0.9.8) works fine.
Working theory in #1146 is that it's a bug in binutils, either linker or
assembler. And the fact that binutils update helped in your case does
not refute it, on the contrary confirms. Can you tell wich binutils
version did you upgrade from? And which version to? A.
To version is 2.16.1.
About from version I am not quite sure -- it could be either 2.11.93 (as
deployed with RedHat 7.3) or some a bit newer version from the former
RedHat up2date system.
Marcel Svitalský
--
**
tlf: (+420) 245 005 546 ... po-pá 8:00-16:30
tlf: (+420) 606 439 651
e-mail: [EMAIL PROTECTED]
e-mail: [EMAIL PROTECTED]
Nebojte se ¹ifrování - ¹ifra je jako obálka na dopise.
Osobní a dùvìrné vìci také nepí¹ete na pohlednici.
GPG public key (ID 0xD98EC83A) fingerprint:
3BEB 4658 A998 B9B3 3476 AD64 EF87 D0A5 D98E C83A
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: mk1mf.pl doesn't generate makefile for Windows CE
Hi, At 25 Jul 2005 11:27:32 +0200 Andy Polyakov wrote: I've been browsing through MSDN and didn't quite figured out where _WIN32_WCE and platform-specific pre-processor macros get assigned/defined. Most notably I used to believe that they're pre- defined by compiler driver itself, but [this time?] I failed to find an explicit reference confirming that this is actually case. I found reference that at least _WIN32_WCE is defined through project preferences as -D_WIN32_WCE=$(CEVersion). Now, VC-32.pl passes down $(WCETARGETDEFS), but does it actually cover _WIN32_WCE? Can you double- check this? Or better yet, can you post how WCETARGETDEFS is [normally] expanded? Compiler doesn't define any _WIN32_WCE, UNDER_CE and so on. So you need to specify explicitly with -D options. Unfortunatelly wcecompat has a bug that it defines _WIN32_CE instead of _WIN32_WCE. For example, for Pocket PC (on WCE300) ARM, WCETARGETDEFS is expanded to -DWCEPLATFORM=MS_POCKET_PC_2000 -DARM -D_ARM_ -DUNDER_CE=300 -D_WIN32_CE=300 -DUNICODE -D_UNICODE I think we need to fix this problem before everything else. The simplest way to fix this problem is to add -D_WIN32_WCE=$(WCEVERSION) after $(WCETARGETDEFS) in makefiles. Well, the way I feel is that currently supported platforms needs definition first:-) And once again [as already mentioned in above mentioned thread] I still fail to see why PPC2003 needs special treatment. I'd rather classify them by _WIN32_WCE value or something similar. In original wcecompat, there are five platforms defined: MS HPC, MS HPC Pro, ms palm size pc, ms pocket pc and Pocket PC 2002. I think ms pocket pc is a good starting point. Because this is the oldest platform which was built on Windows CE 3.0. Before Windows CE 3.0, supports for C runtime library are poorer. In addition, a library built for ms pocket pc can be used on newer Pocket PC platforms. Actually, I can build OpenSSL for MS HPC Pro platform using some patches against wcecompat. But before we start investigating about lacks of C runtime library supports, how about making it compile for ms pocket pc platform? About PPC2003 issue, sometimes it needs platform specific treatment, because APIs are defined for 'Platform' but for 'Version of Windows CE'. But from my experience, these cases are rare and mostly involved in shell APIs or something which may not be used by OpenSSL. I beleive we can classify by _WIN32_WCE (and possibly _WIN32_WCE_PSPC) in most cases. Regards. -- Satoshi Nakamura [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [Fwd: Re: [openssl.org #1171] Unable to pass make test 2]
Andy Polyakov via RT wrote:
test BN_sqr
make[2]: *** [test_bn] Error 139
Could you examine
https://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=1146 and see if
you confirm that it's identical problem.
I am sorry but I cannot reproduce the problem any more. I did these steps
after
reporting the problem till now:
- instaled openssl 0.9.7g instead of 0.9.7e and relinked lib{crypto,ssl}.so
and
dtto.so.0 to this version,
- instaled openssh 4.1 instead of 4.0,
- instaled latest binutils,
- and instaled gcc 3.4.4.
And now it (make make test for openssl 0.9.8) works fine.
Working theory in #1146 is that it's a bug in binutils, either linker or
assembler. And the fact that binutils update helped in your case does
not refute it, on the contrary confirms. Can you tell wich binutils
version did you upgrade from? And which version to? A.
I wrote:
To version is 2.16.1.
About from version I am not quite sure -- it could be either 2.11.93 (as
deployed with RedHat 7.3) or some a bit newer version from the former
RedHat up2date system.
and now, trying rpm -q binutils command (as the new version was the first one
compiled from the source code, previous was/were instaled from RPM(s)), I can
say that from version was binutils-2.11.93.0.2-11.
Marcel Svitalský
--
**
tlf: (+420) 245 005 546 ... po-pá 8:00-16:30
tlf: (+420) 606 439 651
e-mail: [EMAIL PROTECTED]
e-mail: [EMAIL PROTECTED]
Nebojte se ¹ifrování - ¹ifra je jako obálka na dopise.
Osobní a dùvìrné vìci také nepí¹ete na pohlednici.
GPG public key (ID 0xD98EC83A) fingerprint:
3BEB 4658 A998 B9B3 3476 AD64 EF87 D0A5 D98E C83A
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Missing 0 test in BN_mod_word = core dump
Ton Hospel wrote: ... Gives: Floating point exception (core dumped) Reason: unlike in BN_div_word, in BN_mod_word w is not checked for being 0 ok PS: these functions are really bad in that you can't distinguish between failure and a real 0 result. Maybe they should be returning (BN_ULONG) -1, since that value is impossible as normal output agree, returning 0 in case of an error isn't really optimal here and (BN_ULONG)-1 is the only value that can't be the result of a normal operation. Actually the return value in case of an error isn't even specified in the manpage so setting it to (BN_ULONG)-1 shouldn't be too problematic. I will commit a patch soon. Thanks, Nils __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #869] [FWD] [PATCH] OpenSSL patch for CRL Distribution Points for the X.509 Certificate Profile
This has now been implemented in 0.9.9 but using a somewhat different syntax. Ticket resolved. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: mk1mf.pl doesn't generate makefile for Windows CE
I found reference that at least _WIN32_WCE is defined through project preferences as -D_WIN32_WCE=$(CEVersion). I think we need to fix this problem before everything else. The simplest way to fix this problem is to add -D_WIN32_WCE=$(WCEVERSION) after $(WCETARGETDEFS) in makefiles. Can you double-confirm this? MSDN mentions -D_WIN32_WCE=$(CEVersion) and you suggest -D_WIN32_WCE=$(WCEVERSION). Is one wrong or are both right? A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: mk1mf.pl doesn't generate makefile for Windows CE
I found reference that at least _WIN32_WCE is defined through project preferences as -D_WIN32_WCE=$(CEVersion). I think we need to fix this problem before everything else. The simplest way to fix this problem is to add -D_WIN32_WCE=$(WCEVERSION) after $(WCETARGETDEFS) in makefiles. Can you double-confirm this? MSDN mentions -D_WIN32_WCE=$(CEVersion) and you suggest -D_WIN32_WCE=$(WCEVERSION). Is one wrong or are both right? OK, I can see that WCEVERSION is defined in 3rd party wcecompat.mak, but I would feel better if we use variable set by VCVARS*.BAR or whatever it's called in embedded C. Meaning that I'd like to rephrase the question. Can you figure out variables set by VC, which we can use? A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: mk1mf.pl doesn't generate makefile for Windows CE
Hi, At 25 Jul 2005 23:36:41 +0200 Andy Polyakov wrote: Can you double-confirm this? MSDN mentions -D_WIN32_WCE=$(CEVersion) and you suggest -D_WIN32_WCE=$(WCEVERSION). Is one wrong or are both right? OK, I can see that WCEVERSION is defined in 3rd party wcecompat.mak, but I would feel better if we use variable set by VCVARS*.BAR or whatever it's called in embedded C. Meaning that I'd like to rephrase the question. Can you figure out variables set by VC, which we can use? They are OSVERSION, PLATFORM, WCEROOT, SDKROOT, PATH, INCLUDE, LIB, CC, TARGETCPU and CFG. Here is a script from WCEARM.BAT. if %OSVERSION%== set OSVERSION=WCE300 if %PLATFORM%== set PLATFORM=ms pocket pc if %WCEROOT%== set WCEROOT=C:\Program Files\Microsoft eMbedded Visual Tools if %SDKROOT%== set SDKROOT=C:\Program Files\Windows CE Tools set PATH=%WCEROOT%\COMMON\EVC\bin;%WCEROOT%\EVC\%OSVERSION%\bin;%path% set INCLUDE=%SDKROOT%\%OSVERSION%\%PLATFORM%\include;%SDKROOT%\%OSVERSION%\%PLATFORM%\MFC\include;%SDKROOT%\%OSVERSION%\%PLATFORM%\ATL\include; set LIB=%SDKROOT%\%OSVERSION%\%PLATFORM%\lib\arm;%SDKROOT%\%OSVERSION%\%PLATFORM%\MFC\lib\arm;%SDKROOT%\%OSVERSION%\%PLATFORM%\ATL\lib\arm; set CC=clarm.exe set TARGETCPU=ARM set CFG=none CEVersion is set by IDE, so you cannot utilize it from commandline. -- Satoshi Nakamura [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
