Hello Niels, > I think this would be more user-friendle without the "a", > --enable-armv8-crypto, or --enable-arm64-crypto. Or do you foresee any > collision with an incompatible ARMv8-M crypto extension or the like?
FWIW, I like --enable-arm64-crypto because it would nicely match with a directory arm64/crypto for the source and the idea of enabling the crypto extension for the arm64 target of nettle and be in line with --enable-arm-neon and arm/neon as well. > > + aarch64*) > > + if test "$enable_armv8_a_crypto" = yes ; then > > + if test "$ABI" = 64 ; then > > + CFLAGS="$CFLAGS -Wa,-march=armv8-a+crypto" > (This looks slightly different after merging all the changes). > I think it's unfortunate to have to modify CFLAGS, and in particular > using compiler-specific options. Is there any way to use a pseudoop in > the .asm file instead, similar to the .fpu neon used in the arm/neon/ > files? With binutils gas, both .arch and .arch_extension seem to do what you describe. Based on when they appeared in the manual, both are supported in gas since 2.26[4]. I've done a quick test with 2.35.1. I have successfully tried both .arch armv8-a+crypto (the -a is required here, otherwise errors are still thrown for uses of pmull with just armv8 or armv8-r) and .arch_extension crypto The testsuite still runs with both on LE and BE cross-compiled and run under qemu-user. binutils 2.26 also know the crypto extension name and were released January 2016. aarch64 support seems to have been introduced in 2.23 (October 2012) and with 2.25 (July 2015) the crypto flag to the -march command line option was added. (All based on when it appeared in the documentation.) So we'd likely have a dependency on 2.25 by using the -march option already and 2.26 wouldn't be a big step. [4] https://sourceware.org/binutils/docs-2.26/as/AArch64-Directives.html All this is gas-specific though, I would assume. Some discussion of compatible extensions to llvm-as seems to have happened in 2018 but I have not researched what came out of it[5]. The recent date and that it's the first search hit and no others link to documentation or such doesn't bode well IMO. It might as well be that llvm-as just knows the pmull instruction and assembles it fine but can't check if the target CPU will be able to run it. [5] https://lists.llvm.org/pipermail/llvm-dev/2018-September/126346.html What other assemblers for aarch64 do you have in mind? -- Thanks, Michael _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
