Hi, Just my 2 cents about this. armv8-a is the architecture of the arm core, while aarch64/aarch32 is the execution mode on said architecture. So I believe that we should have overrides for BOTH the architecture and the execution mode, as you can have armv8-a executing in 32 bits mode - and btw, the instruction set in 32 bits mode is not exactly the same as armv7-ve, so in terms of optimization it does help to know you're running on an armv8-a architecture, even if it's in 32 bits mode. There was no such problem before armv8-a architecture, since all previous architectures were running in 32 bits mode only. Armv8-a changes that as it's a "hybrid", with support for both aarch64 and aarch32. I expect later arch to support only aarch64.
There is also an additional thing to consider, there is not just one armv8-a profiles, there already are several, and they shall all be taken into account. I believe that at this time, the valid ones are armv8.0-a, armv8.1-a, armv8.2-a, armv8.3-a and armv8.4-a. And let me answer before someone asks, yes the gcc compiler DOES provide compiler options for all those architectures, with those exact names - except armv8.0-a is just named armv8-a (-march=armv8-a or -march=armv8.[1,2,3,4]-a). So it just makes sense to support them all. So overall, I believe we should support all those arm v8 architectures, and add the corresponding override to the cpu definition files (for instance, as Peter mentioned, cortex-a53 is an armv8.0-a. But a cortex-a55 or cortex-a75 would be an armv8.2-a). Finally, the arm architecture is slightly more complex than just armv8.x-a, since the support for "features" is optional. So at least "crc" and "crypto" features should be added, in order to have a "comprehensive" view of the armv8 architecture. And yes, the "features" are also supported by the gcc compiler. So the arm architecture would really be fully defined by armv8.x-a+[no]crc+[no]crypto, depending on the underlying SoC and what they implemented or not as optional features. And this is probably what should end up going into the tune-cortexa53.inc and others (and should be override-able, since again not all cortexa53 are created the same). Cheers, Herve -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Peter Kjellerstedt Sent: 03 March 2020 13:00 To: Junling Zheng <[email protected]>; Khem Raj <[email protected]>; [email protected] Cc: [email protected] Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 in MACHINEOVERRIDES > -----Original Message----- > From: [email protected] > <openembedded-core- [email protected]> On Behalf Of > Junling Zheng > Sent: den 3 mars 2020 04:11 > To: Khem Raj <[email protected]>; openembedded- > [email protected] > Cc: [email protected] > Subject: Re: [OE-core] [PATCH] arch-arm64.inc: Do not append aarch64 > in MACHINEOVERRIDES > > On 2020/3/3 2:29, Khem Raj wrote: > > > > > > On 3/2/20 9:11 AM, Junling Zheng wrote: > >> Currently, for arch-arm64, poky will append the MACHINEOVERRIDES > >> with "aarch64:", which has the higher priority than TRANSLATED_TARGET_ARCH. > >> So, for aarch64 big endian, the variable '<foo>_aarch64' will > >> override not only '<foo>', but also '<foo>_aarch64-be', thus we > >> will get an incorrect variable. > >> > >> Signed-off-by: Junling Zheng <[email protected]> > >> --- > >> meta/conf/machine/include/arm/arch-arm64.inc | 2 -- > >> 1 file changed, 2 deletions(-) > >> > >> diff --git a/meta/conf/machine/include/arm/arch-arm64.inc > b/meta/conf/machine/include/arm/arch-arm64.inc > >> index 53f4566815..32294bd218 100644 > >> --- a/meta/conf/machine/include/arm/arch-arm64.inc > >> +++ b/meta/conf/machine/include/arm/arch-arm64.inc > >> @@ -4,8 +4,6 @@ require conf/machine/include/arm/arch-armv7ve.inc > >> TUNEVALID[aarch64] = "Enable instructions for aarch64" > >> -MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', 'aarch64:', '' ,d)}" > >> - > > > > if its removed here, where is it being added for other machines, > question is, should we treat aarch64 as LE equivalent of aarch64_be > > or should be treated as common aarch64 and a new define like > > aarch64_le > defined. > > > > Currently, for arm64, we have aarch64_be to represent big endian, but > no overrides to represent little endian only. > > So, IMO, we should treat aarch64 as little enaian only, like arm and > armeb. > > >> # Little Endian base configs > >> AVAILTUNES += "aarch64 aarch64_be" > >> ARMPKGARCH_tune-aarch64 ?= "aarch64" Please, before removing "aarch64" from MACHINEOVERRIDES, add "armv8a" or similar. This is how it is done for the armv7* based chips. E.g., I would expect to see tune-cortexa53.inc have: MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'cortexa53', 'armv8a:', '' ,d)}" Which corresponds to how it is done for armv7*. At least we currently rely on being able to do, e.g.: COMPATIBLE_MACHINE = "aarch64|armv7a|armv7ve" and if you remove "aarch64" from MACHINEOVERRIDES, we need a suitable substitute. //Peter -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
