On Tue, Jan 5, 2021 at 5:52 PM Maamoun TK maamoun.tk@googlemail.com wrote:
On Tue, Jan 5, 2021 at 3:23 PM Niels Möller nisse@lysator.liu.se 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 maamoun.tk@googlemail.com wrote:
On Tue, Jan 5, 2021 at 3:23 PM Niels Möller nisse@lysator.liu.se 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=be2b567018d987591647935a7c9648e9...
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