Should we move aarch32 to CRYPTOPP_ARM32 variable?

[CAMOBAP]

As far as I understood aarch32 is an alias for armv8 32bit. According to this should we apply this diff?

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -299,8 +299,8 @@ DumpMachine(CRYPTOPP_AMD64 "(x86_64|AMD64|amd64)")
 DumpMachine(CRYPTOPP_I386 "^i.86$")
 DumpMachine(CRYPTOPP_MINGW32 "^mingw32")
 DumpMachine(CRYPTOPP_MINGW64 "(w64-mingw32)|(mingw64)")
-DumpMachine(CRYPTOPP_ARMV8 "(armv8|aarch32|aarch64)")
-DumpMachine(CRYPTOPP_ARM32 "(arm|armhf|arm7l|eabihf)")
+DumpMachine(CRYPTOPP_ARMV8 "(armv8|aarch64)")
+DumpMachine(CRYPTOPP_ARM32 "(arm|armhf|arm7l|eabihf|aarch32)")
 DumpMachine(CRYPTOPP_PPC32 "^(powerpc|ppc)")
 DumpMachine(CRYPTOPP_PPC64 "^ppc64")

[noloader]

As far as I understood aarch32 is an alias for armv8 32bit. According to this should we apply this diff?

No. Aarch32 is ARMv8 architecture. ARMv8 has AES, CRC32, PMULL and SHA. ARM A-32 lacks them.

[CAMOBAP]

@noloader to be on the same page is it possible to compile cryptopp for armv8 32bit mode?

[noloader]

@camobap,

armv8 32bit mode?

If we are not crossing our definitions, that's Aarch32. Aarch32 is an execution environment with Aarch64 machine. That is controlled by the compiler, like the way you can setup a compiler for armel or armhf. For Aarch32 you might add some compiler switches.

I don't know what the compiler switches are for Aarch32. I tried to setup a test platform for aarch32 4 or 5 years ago. No one seemed to know how to setup the platform or what switches to use. I suspect compilers were not supporting Aarch32 at the time.

In case we are crossing our definitions, early Aarch64 boards often used an armhf image. Early RaspberryPi images did this. That was also supported by the compiler. There was nothing special to do for this platform. From our (non-kernel) view of the world it looks like were are building for armhf.

I believe (but don't know for sure) that -mfpu=neon-fp-armv8 is the important option for Aarch32. You would use it as part of a cross-compile, or use it on a Aaarch64 when performing an Aarch32 compile. Also see How to test Aarch32 execution environment on Aarch64? and -mfpu=neon-fp-armv8 and unrecognized command.

[noloader]

@camobap,

Here's what armhf looks like from a RaspberryPi 3. It uses a Raspbian image. Note the __arm__ and __armel__ define.

pi@rpi3:~ $ g++ -dM -E - </dev/null | grep -i -E 'arm|arch|neon'
#define __ARM_SIZEOF_WCHAR_T 4
#define __ARM_FEATURE_SAT 1
#define __ARM_ARCH_ISA_ARM 1
#define __ARMEL__ 1
#define __ARM_FEATURE_UNALIGNED 1
#define __ARM_FP 12
#define __ARM_SIZEOF_MINIMAL_ENUM 4
#define __ARM_PCS_VFP 1
#define __ARM_FEATURE_LDREX 4
#define __ARM_FEATURE_QBIT 1
#define __ARM_ARCH_6__ 1
#define __ARM_32BIT_STATE 1
#define __ARM_FEATURE_CLZ 1
#define __ARM_ARCH_ISA_THUMB 1
#define __ARM_ARCH 6
#define __arm__ 1
#define __ARM_FEATURE_SIMD32 1
#define __ARM_FEATURE_COPROC 15
#define __ARM_EABI__ 1
#define __ARM_FEATURE_DSP 1

Here's what Aarch64 looks like. Notice how the compiler is setup differently from armhf. Note the __aarch64__ define:

noloader@gcc118:~> g++ -dM -E - </dev/null | grep -i -E 'arm|arch|neon'
#define __ARM_SIZEOF_WCHAR_T 4
#define __ARM_FEATURE_UNALIGNED 1
#define __ARM_FEATURE_IDIV 1
#define __ARM_FP 14
#define __AARCH64_CMODEL_SMALL__ 1
#define __ARM_ALIGN_MAX_STACK_PWR 16
#define __ARM_SIZEOF_MINIMAL_ENUM 4
#define __ARM_ALIGN_MAX_PWR 28
#define __ARM_FP16_FORMAT_IEEE 1
#define __aarch64__ 1
#define __ARM_FP16_ARGS 1
#define __ARM_FEATURE_FMA 1
#define __ARM_64BIT_STATE 1
#define __ARM_ARCH_PROFILE 65
#define __ARM_PCS_AAPCS64 1
#define __AARCH64EL__ 1
#define __ARM_FEATURE_CLZ 1
#define __ARM_ARCH 8
#define __ARM_ARCH_8A 1
#define __ARM_NEON 1
#define __ARM_FEATURE_NUMERIC_MAXMIN 1
#define __ARM_ARCH_ISA_A64 1

And at try at Aarch32:

noloader@gcc118:~> g++ -mfpu=neon-fp-armv8 -dM -E - </dev/null | grep -i -E 'arm|arch|neon'
g++: error: unrecognized command line option ‘-mfpu=neon-fp-armv8’