On Tue, Jan 5, 2021 at 5:52 PM Maamoun TK <[email protected]> wrote:
> On Tue, Jan 5, 2021 at 3:23 PM Niels Möller <[email protected]> wrote: > >> > I wonder which assembly files we should use if target host is aarch64, >> > but ABI=32? I guess the arm/v6/ code can be used unconditionally. Can >> > we also use arm/neon/ code unconditionally? >> >> The reference manual says >> >> Armv8 can support the following levels of support for Advanced SIMD and >> floating-point instructions: >> >> * Full SIMD and floating-point support without exception trapping. >> >> * Full SIMD and floating-point support with exception trapping. >> >> * No floating-point or SIMD support. This option is licensed only for >> implementations targeting specialized markets. >> >> As far as I understand, that means Neon should be always available, in >> both 32-bit and 64-bit mode. >> > > I'll investigate how we can build the existing NEON implementations on > 64-bit systems. > I spent some time investigating and testing, it looks like aarch64 gcc can not handle 32-bit assembly code currently. In order to build 32-bit arm binaries on 64-bit systems, one has to use 'gcc-arm-linux-gnueabi' or 'gcc-arm-linux-gnueabihf' toolchains, I went through the options available in aarch64 gcc https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html but none of which allow us to use 32-bit assembly code even '-mabi=ilp32' doesn't do that as I get the same errors with or without it. I'm afraid that we need to re-write the 32-bit assembly code in 64-bit format in order to get those optimizations enabled in 64-bit arm binaries. regards, Mamone On Tue, Jan 5, 2021 at 5:52 PM Maamoun TK <[email protected]> wrote: > On Tue, Jan 5, 2021 at 3:23 PM Niels Möller <[email protected]> wrote: > >> I've made a new branch "arm64" with the configure changes. If you think >> that looks ok, can you add your new ghash code on top of that? >> > > Great. I'll add the ghash code to the branch once I finish the big-endian > support. > > >> (It would be good to also >> get S390x into the ci system, before adding s390x-specific assembly. I >> hope that should be easy to do with the same cross setup as for arm, >> arm64, mips, etc). >> > > This is not possible since qemu doesn't support cipher functions, it > implements subcode 0 (query) without actual encipher/decipher operations, > take a look here > > https://git.qemu.org/?p=qemu.git;a=commit;h=be2b567018d987591647935a7c9648e9c45e05e8 > > > I had a talk with David Edelsohn for this issue, I concluded that there is > no support for cipher functions on qemu and it's unlikely to happen anytime > soon. However, I updated the testutils to cover the s390x-specific assembly > so the patch can easily be tested manually by executing 'make check'. I > also have tested every aspect of this patch to make sure everything will go > well once it's merged. > > > I wonder which assembly files we should use if target host is aarch64, >> > but ABI=32? I guess the arm/v6/ code can be used unconditionally. Can >> > we also use arm/neon/ code unconditionally? >> >> The reference manual says >> >> Armv8 can support the following levels of support for Advanced SIMD and >> floating-point instructions: >> >> * Full SIMD and floating-point support without exception trapping. >> >> * Full SIMD and floating-point support with exception trapping. >> >> * No floating-point or SIMD support. This option is licensed only for >> implementations targeting specialized markets. >> >> As far as I understand, that means Neon should be always available, in >> both 32-bit and 64-bit mode. >> > > I'll investigate how we can build the existing NEON implementations on > 64-bit systems. > > regards, > Mamone > _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
