This is a discussion on Re: [openssl.org #1693] Compiling OpenSSL with mingw-w64 - Openssl ; > There is no assembly support for pe64. Well, Win64 ABI is fully supported by OpenSSL x86_64 assembler modules. There is no support for GNU assembler under Win64, but masm (rather known as ml64) and nasm are fully supported (though ...
> There is no assembly support for pe64.
Well, Win64 ABI is fully supported by OpenSSL x86_64 assembler modules.
There is no support for GNU assembler under Win64, but masm (rather
known as ml64) and nasm are fully supported (though there are
requirements for least supported versions, for nasm it's 2.03).
> So no assembly is available.
If assembler was to be added to mingw64, I'd rather deploy nasm. It
would be easiest.
> Can someone estimate if it is better to use 32bit with assembly than
> 64bit without?
64-bit algorithms, most notably SHA512, would perform better with 64-bit
compiler, while 32-bit assembler is likely to outperform it on 32-bit
algorithms (such as everything else symmetric). Indeed, 32-bit assembler
normally delivers ~80% of 64-bit assembler on 32-bit algorithms (not on
SHA256 though), so assuming that 64-bit assembler gives at least 30%
improvement over 64-bit compiler generated code... As for BN
performance. As it is *now*, 32-bit assembler would perform
approximately as fast as (if not better) 64-bit compiler generated code,
but[!] it's possible to improve the latter. Try following. In bn_lcl.h
there is BN_UMULT_HIGH definition in #elif defined(__x86_64) &&
defined(SIXTY_FOUR_BIT_LONG) in __GNUC__. Replace last defined() with
(defined(SIXTY_FOUR_BIT_LONG) || defined(SIXTY_FOUR_BIT)). This will
give significant performance improvement. Please verify.
> I am not fully sure that the crypto/sha/sha512.c is correct, it
> simulate the behavior of win64 using Microsoft compiler, using
> _rotr64 function as ROTR.
What you should have done instead is to modify macro in question
declaring ret as unsigned long long. If it doesn't work, then it's more
appropriate to leave ROTR undefined, i.e. *not* using _rotr64. Please
Also. As NT is natively UNICODE, and there are no non-NT Win64
implementations(*), there is no reason to favor legacy ANSI interfaces.
Could you verify that it compiles and works with -DUNICODE -D_UNICODE
added to config line? A.
(*) this is unlike Win32, which was available as NT and Win9x, where
latter was natively ANSI.
OpenSSL Project http://www.openssl.org
Development Mailing List firstname.lastname@example.org
Automated List Manager email@example.com