> NASM has another hidden benefit for distros and app suppliers. Using NASM,
> we could provide, say, NASM_SSE2_SomeFunc and NASM_AVX_SomeFunc from a
> single source file. We can't currently do that because when we enable AVX
> for NASM_AVX_SomeFunc, then SSE4 and AVX could cross-pollinate into
> NASM_SSE2_SomeFunc. That will result in an "Illegal Instruction" exception.
>
> If things work well, then we could extend NASM to all platforms, like X86
> and X64 on Windows and Linux. But that's just wishful thinking at the
> moment.
>
By the way, this experiment has been privately running in my test rigs for
some time now because RDRAND and RDSEED are in a similar setup. Its the
reason rdrand.cpp is set-up like it is:
* C++ function that calls ASM routine
* can provide intrinsic-based routine
* https://github.com/weidai11/cryptopp/blob/master/rdrand.cpp
* Microsoft MASM ASM routines
* https://github.com/weidai11/cryptopp/blob/master/rdrand.asm
* Linux ASM routines
* https://github.com/weidai11/cryptopp/blob/master/rdrand.S
As I was explaining to Wei, part of the problem that I see in testing is:
too many choices. We can us C/C++ with intrinsics; we can use MS MASM
(rdrand.asm); or we can use NASM assmbler (rdrand.S).
It would be very appealing to fold rdrand.asm and use rdrand.S, and then us
rdrand.S everywhere.
Jeff
Jeff
--
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [email protected].
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
---
You received this message because you are subscribed to the Google Groups
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
