Nikos Mavrogiannopoulos <n.mavrogiannopou...@gmail.com> writes: > A solution to that issue would be to have a nettle library constructor > that runs the equivalent of cpuid in ARM, and stores it to a global > variable. Then each assembly module (e.g., aes-arm) will jump to the > correct implementation detected at runtime.
The difficult part is the configure work. We'd either have to build multiple object files for each function, with different link names, and then have some glue to select the right one at runtime. Or use a "master file" for each function, say arm/fat/foo.asm, which includes the other files and makes the right thing happen. Things get a bit more complex if we need to use the C version on some machines, since the current build setup assumes that an assembly file completely replaces the corresponding C file. There's also IFUNC relocations, but I'm not sure which systems beyond vanilla gnu/linux support them. Are they usable on android, e.g.? I clearly see the need for a runtime test for neon. Say, --enable-arm-neon=fat or a more general --enable-fat. But you also mention v6 optimizations, for clarity, do you mean that you'd like to see runtime tests for that as too? To me, it seems a bit unlikely to need a fat binary which supports both pre-v6 arm, and v6 and later. I'd expect pre-v6 arm to be used only in embedded systems where the cpu flavor is known at build time. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
