Add armv8* arch variants to rpmrc.in #425

berolinux · 2018-03-30T14:40:09Z

armv8* is aarch64 machines in 32-bit mode

Signed-off-by: Bernhard Rosenkränzer bero@lindev.ch

Conan-Kudo · 2018-03-30T18:34:21Z

rpmrc.in

@@ -461,6 +472,8 @@ arch_compat: armv5tl: armv4tl
 arch_compat: armv4tl: armv4l
 arch_compat: armv4l: armv3l
 arch_compat: armv3l: noarch
+arch_compat: armv8hnl: armv8hl
+arch_compat: armv8hl: armv7hnl


This is not compatible. This does not describe a true superset to subset case.

Since NEON is mandatory on aarch64, armv8hnl and armv8hl are the same thing, so it does describe a true superset to subset case. (To be even more correct, should probably add arch_compat: armv8hl: armv8hnl -- but I don't think circular loops there are a good idea.)

It may be worth arguing armv8hnl shouldn't exist at all (because armv8hl is the same and therefore the extra n is superfluous) or armv8hl shouldn't exist at all (because armv8hnl is the same and having the n in there is consistent with what was done on armv7) -- I've put in both for now to be compatible with what either side would expect.

Conan-Kudo · 2018-03-30T18:34:35Z

rpmrc.in

@@ -593,6 +607,8 @@ buildarch_compat: armv4tl: armv4l
 buildarch_compat: armv4l: armv3l
 buildarch_compat: armv3l: noarch

+buildarch_compat: armv8hnl: armv8hl
+buildarch_compat: armv8hl: armv7hnl


This is not compatible. This does not describe a true superset to subset case.

Conan-Kudo · 2018-03-30T18:35:47Z

rpmrc.in

@@ -80,6 +80,9 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard -mfpu=vfp
 optflags: armv7l -O2 -g -march=armv7
 optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16
 optflags: armv7hnl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=neon
+optflags: armv8l -O2 -g -march=armv8-a
+optflags: armv8hl -O2 -g -march=armv8-a -mfloat-abi=hard -mfpu=neon


armv8hl should not have neon.

Same here, since NEON is mandatory for ARMv8 (that's why there is no -mfpu= switch in the aarch64-* compilers), armv8hl and armv8hnl are the same and -mfpu=neon will do the right thing.

I don't see any use case for the combination of armv8-a and -mfpu=something other than neon, except in the softfloat case (armv8l) if you need to use a binary-only library that still doesn't support hardfloat (Android...)

Technically speaking, NEON is mandatory for the 64-bit ISA, but as far as I'm aware, that is not the case for the 32-bit ISA. AArch32 v8 still allows NEON to be omitted.

berolinux · 2018-04-01T07:59:38Z

According to http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/CJHECGIH.html, "Both floating-point and NEON are required in all standard ARMv8 implementations", but "implementations targeting specialized markets may support the following combinations:
No NEON or floating-point." -- so armv8hl without n can make some sense for specialized CPU variants. Should probably strongly encourage armv8hnl w/ buildarchtranslate though, given mostly everyone will target standard armv8...

Conan-Kudo

Looks good to me! Nice job! 👍

Conan-Kudo

Small suggestions.

Conan-Kudo · 2018-04-01T08:05:34Z

rpmrc.in

@@ -80,6 +80,9 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard -mfpu=vfp
 optflags: armv7l -O2 -g -march=armv7
 optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16
 optflags: armv7hnl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=neon
+optflags: armv8l -O2 -g -march=armv8-a
+optflags: armv8hl -O2 -g -march=armv8-a -mfloat-abi=hard -mfpu=vfpv4-d16


I'd suggest changing this to -mfpu=vfpv4

Conan-Kudo · 2018-04-01T08:06:33Z

rpmrc.in

@@ -80,6 +80,9 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard -mfpu=vfp
 optflags: armv7l -O2 -g -march=armv7
 optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16
 optflags: armv7hnl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=neon
+optflags: armv8l -O2 -g -march=armv8-a
+optflags: armv8hl -O2 -g -march=armv8-a -mfloat-abi=hard -mfpu=vfpv4-d16
+optflags: armv8hnl -O2 -g -march=armv8-a -mfloat-abi=hard -mfpu=neon


There appears to be an armv8 variant of the neon fpu mode, so maybe we should use it? -mfpu=neon-fp-armv8

kwizart · 2018-04-03T13:19:14Z

armv8* is aarch64 machines in 32-bit mode.

What is aarch32 then ? (open question).

kwizart · 2018-04-03T13:25:58Z

rpmrc.in

@@ -80,6 +80,10 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard -mfpu=vfp
 optflags: armv7l -O2 -g -march=armv7
 optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16
 optflags: armv7hnl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=neon
+optflags: armv8l -O2 -g -march=armv8-a


Do you implicitly really means -mfloat-abi=soft ? I anyone still care about this today ?

aarch32 is the new marketing name for what we used to call the 'arm instruction set'. armv8 is the most current incarnation of the 32-bit ARM instruction set.

While the armv8 spec strongly suggests the inclusion of the VFP/Neon and other instructions. It is not strictly required. So yes, softfloat is still being used and is needed in some cases.

There are multiple ARM licenses who claim to have armv8 compatible CPUs that do not have floating point units. (Note, all of the cases I know of these are 32-bit CPUs -- and all are geared toward embedded.)

@kwizart yes, implicit still is -mfloat-abi=soft (both in clang and gcc) even though I haven't seen that used on any general purpose CPU in ages -- nobody wants to change what everyone has come to expect.

berolinux · 2018-04-04T23:15:12Z

@n3npq At least in the arm world it's somewhat less insane: uname -m shows what it should, armv7 vs armv8 vs aarch64 etc. is 100% consistent across all processors regardless of manufacturer and marketing names.

mlschroe · 2018-04-05T09:20:18Z

Pardon the dumb question, but if armv8 is just the 32bit mode of aarch64 why doesn't aarch64 also need those float/neon/crypto modifiers?

berolinux · 2018-04-05T11:36:29Z

@mlschroe aarch64 and armv8 are the same CPU, but (obviously, given one is 32bit and one is 64bit) a different ABI -- no need to carry over the legacy float ABI.

For neon, all aarch64 CPUs made so far have it, and it is part of the aarch64 core - however, ARM's docs say "Both floating-point and NEON are required in all standard ARMv8 implementations. However, implementations targeting specialized markets may support the following combinations:
No NEON [...]"

Neither gcc nor clang support aarch64 ABI without NEON for now, so targeting such a CPU is hypothetical anyway.
So far, the only specialized implementations were 32-bit anyway, but we can't rule out a special purpose aarch64 CPU without neon coming out at some point.
Given those (if they ever appear) will be rare and non-standard, if they're worth supporting at all they should probably get a modifier instead of discouraging people targeting aarch64 from using neon.

For crypto, a modifier may well be useful, aarch64 CPUs exist both with and without the crypto extensions.
Do we want to go there even though we don't have something comparable in the x86_64 world where it may make sense to have modifiers for SSE4, AVX, AVX2, SSE4a, SSE4.1, SSE4.2, .....?

mhatle · 2018-04-05T13:49:29Z

@berolinux Just to be clear, I -have- a customer who has asked for armv8 WITHOUT NEON/VFP. This was obviously in the embedded space, but the same customer is saying that it's not for compatibility, but is actually a 32-bit 'armv8' processor. (No 64-bit support..) I have no idea if those claims are true or not, as I've not directly worked on that processor. Thus the mass confusion continues.

But I agree with you, all aarch64 CPUs I have seen include all of the prescribed hardware as indicated by the spec. There may be some instruction scheduling differences, but so far the instruction set has been consistent and compatible.

But with that said, I agree with what @n3npq mentioned above. Having these indicates as part of the package 'name' (other then for human readable purposes) really no longer makes sense. Between compatibility frameworks, emulators, etc... the system and users should be able to specify compatibility and priority and just 'go from there'. Same with package generation. It would make my life easier (using RPM in embedded systems) to get rid of this rpmrc notion for anything more then 'human readable'.

armv8* is aarch64 machines in 32-bit mode Also fix %arm macro to include newer processor types Signed-off-by: Bernhard Rosenkränzer <bero@lindev.ch>

pmatilai · 2018-04-16T10:38:53Z

My largely uneducated take in this is... how about we just forget the exception clause about specialized environments and just define armv8 in rpm to mean standard armv8?

mhatle · 2018-04-17T19:57:08Z

@pmatilai someone brought to my attention today there is various confusion as to what 'armv8' actually means (for a package type).

Does it mean traditional 32-bit ABI using instructions available on an 'ARMv8' processor?

or does it mean using ILP32 ABI using all of the aarch64 instructions?

In the former case, the ABI is compatible with armv7 and older.. in the later case, it's a new ABI.

If you can make it clear ARMv8 is just the compatible with everything else version -- then it's just another marker... someone can add something new for ilp32 mode, if it is ever implemented.

berolinux · 2018-04-17T20:03:07Z

I think this makes most sense (and is what I implemented in the original patch):
armv8l == old ABI compatible with armv7l
armv8hl == old hardfloat EABI compatible with armv7hl
armv8hnl == armv8hl + neon, compatible with armv7hnl
armv8hcnl == armv8hnl + crypto extensions

ILP32, if properly implemented, probably needs a new name (if not a variant of aarch64, given it's closer to aarch64 than to armv7hnl? I'd be leaning towards aarch64_32 or something like that)

pmatilai · 2018-10-01T12:51:07Z

Since neither objections or anything new has come up in all this time, about time we merged this.

Thanks for the patch and sorry for taking so long.

Conan-Kudo suggested changes Mar 30, 2018

View reviewed changes

berolinux force-pushed the armv8 branch from 7a3ba57 to 2658701 Compare April 1, 2018 07:56

Conan-Kudo approved these changes Apr 1, 2018

View reviewed changes

berolinux force-pushed the armv8 branch from 2658701 to cdc69d2 Compare April 1, 2018 08:06

Conan-Kudo suggested changes Apr 1, 2018

View reviewed changes

berolinux force-pushed the armv8 branch from cdc69d2 to 3a7ff9a Compare April 1, 2018 08:09

Conan-Kudo approved these changes Apr 1, 2018

View reviewed changes

kwizart reviewed Apr 3, 2018

View reviewed changes

Conan-Kudo mentioned this pull request Apr 10, 2018

Fix %arm macro to include newer processor types #428

Merged

Add armv8* arch variants to rpmrc.in and %arm macro

dd5e28c

armv8* is aarch64 machines in 32-bit mode Also fix %arm macro to include newer processor types Signed-off-by: Bernhard Rosenkränzer <bero@lindev.ch>

berolinux force-pushed the armv8 branch from 3a7ff9a to dd5e28c Compare April 10, 2018 18:32

pmatilai merged commit b1f81b8 into rpm-software-management:master Oct 1, 2018

pmatilai mentioned this pull request Oct 18, 2019

Fixes for some issues on Arm platforms #901

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add armv8* arch variants to rpmrc.in #425

Add armv8* arch variants to rpmrc.in #425

berolinux commented Mar 30, 2018

Conan-Kudo Mar 30, 2018

berolinux Mar 30, 2018

Conan-Kudo Mar 30, 2018

Conan-Kudo Mar 30, 2018

berolinux Mar 30, 2018

Conan-Kudo Apr 1, 2018

berolinux commented Apr 1, 2018

Conan-Kudo left a comment

Conan-Kudo left a comment

Conan-Kudo Apr 1, 2018

Conan-Kudo Apr 1, 2018

kwizart commented Apr 3, 2018 •

edited

Loading

kwizart Apr 3, 2018

mhatle Apr 3, 2018

berolinux Apr 4, 2018

berolinux commented Apr 4, 2018

mlschroe commented Apr 5, 2018

berolinux commented Apr 5, 2018

mhatle commented Apr 5, 2018

pmatilai commented Apr 16, 2018

mhatle commented Apr 17, 2018

berolinux commented Apr 17, 2018

pmatilai commented Oct 1, 2018

Add armv8* arch variants to rpmrc.in #425

Add armv8* arch variants to rpmrc.in #425

Conversation

berolinux commented Mar 30, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

berolinux commented Apr 1, 2018

Conan-Kudo left a comment

Choose a reason for hiding this comment

Conan-Kudo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kwizart commented Apr 3, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

berolinux commented Apr 4, 2018

mlschroe commented Apr 5, 2018

berolinux commented Apr 5, 2018

mhatle commented Apr 5, 2018

pmatilai commented Apr 16, 2018

mhatle commented Apr 17, 2018

berolinux commented Apr 17, 2018

pmatilai commented Oct 1, 2018

kwizart commented Apr 3, 2018 •

edited

Loading