On Wed, Jul 20, 2016 at 3:04 PM, Jeffrey Walton <[email protected]> wrote: > Thanks Jim. According to ARM, ARMv8 is 64-bit > (http://www.arm.com/products/processors/armv8-architecture.php). Maybe > I'm parsing the page incorrectly?
The armv8 architecture spec has both aarch32 (32-bit) and aarch64 (64-bit) support. However, for over two decades, we have had an arm gcc port that only emits 32-bit code. If we rename that to aarch32, we break two decades of backward compatibility. Hence, for gcc, arm* always means 32-bit. If you mean 64-bit, then you have to use aarch64. Since aarch64 is not a simple extension of the armv7 architecture to 64-bits, but rather a new architecture with some backward compatibility, we actually have two different compiler ports for armv8 support, the old arm compiler that emits 32-bit code only and the new aarch64 port that emits 64-bit code only. Both are capable of emitting ARMv8 code. Only the arm port can emit ARMv7 code. Similarly, the kernel uses "arm" and "arm64", because they were unwilling to redefine what armvX means, and they were unwilling to rename the arm port to aarch32. Arm and arm64 are distinctly different kernel ports. > OK, thanks. So is neon-fp-armv8 an Aarch32 execution environment option? I think "execution environment" is the wrong way to look at this. There are two different compilers. Arm and aarch64 are treated like two separate architectures, each with its own separate compiler port. It is possible to run an arm cross aarch64 compiler in the aarch32 execution environment, and it is possible to run an aarch64 cross arm compiler in the aarch64 execution environment. The important bit is which compiler you are using, not your execution environment. -mfpu=neon-fp-armv8 is an option accepted by the arm compiler. it is not accepted by the aarch64 compiler. if you use the -mfpu=neon-fp-armv8 option with the arm compiler, that tells it to emit Neon and FP code using the armv8 architecture. > So it looks like the course of action is to simply remove it from > http://github.com/weidai11/cryptopp/blob/master/cryptest.sh#L874 . (It > was added recently because of the ML recommendation). It should be moved from the IS_ARM64 section to the IS_ARM32 section. it is an arm option, not an aarch64 option. The code as written will only work if you are running 32-bit code on a 64-bit kernel, but that should be OK. You already have support for the 32-bit kernel in checking for neon. So if you have both the neon and the asimd checks, then you are supporting code running on both 32-bit and 64-bit kernels. This assumes that no cross compiler will be used, as the /proc/cpuinfo check won't work in that case. > These ARM options are awful. I spent the better part of a day trying > to untangle the option combinations to ensure we are getting good test > coverage in a test script. I'd give my left arm device for a compiler > that provides -march=native or -mfpu=native and gets it right. Both the arm and aarch64 compilers support -march=native, but this doesn't solve the arm FPU problem. For arm, it is possible to run a soft-float rootfs on a hard float part, so we can't tell whether to emit FP code based on the CPU. A reasonable default must be built into the compiler, and if you want something different, you have to request it on the command line. For aarch64, FP and SIMD support is required, so it is just a question of whether crc and/or crypto is supported, and -march=native can handle that as there is no ABI change when enabling/disabling them. Jim _______________________________________________ linaro-toolchain mailing list [email protected] https://lists.linaro.org/mailman/listinfo/linaro-toolchain
