[cfe-dev] [RFC] Make "requires arm" also include AArch64 in module map files

[Ben Langmuir]

Thanks for all the feedback everyone. It sounds like we should go with “aarch32” for the 32-bit arm variants and “arm” = aarch32 || aarch64. I’ll probably land this in the next couple of days.

Ben

> On Jul 29, 2015, at 10:31 AM, Kristof Beyls <kristof.beyls at arm.com> wrote:
> 
> 
> Hi Ben,
> 
> I prefer aarch32 to refer to the 32-bit state, as that is it's defined
> meaning in the ARM glossary, see http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.aeg0014g/ABCDEFGH.html:
> 
> """
> AArch32 state:
> 
> The ARM 32-bit Execution state that uses 32-bit general purpose registers, and a 32-bit program counter (PC), stack pointer (SP), and link register (LR). AArch32 Execution state provides a choice of two instruction sets, A32 and T32.
> In implementations of versions of the ARM architecture before ARMv8, and in the ARM R and M architecture profiles, execution is always in AArch32 state.
> """
> 
> In contrast, arm32 doesn't have a definition like that.
> 
> Thanks,
> 
> Kristof
> 
>> -----Original Message-----
>> From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu]
>> On Behalf Of Ben Langmuir
>> Sent: 29 July 2015 17:49
>> To: Tim Northover
>> Cc: Richard Smith; Clang
>> Subject: Re: [cfe-dev] [RFC] Make "requires arm" also include AArch64 in
>> module map files
>> 
>> 
>>> On Jul 28, 2015, at 9:39 AM, Tim Northover <tnorthover at apple.com>
>> wrote:
>>> 
>>> On 28 Jul 2015, at 06:32, Ben Langmuir <blangmuir at apple.com> wrote:
>>>> Do you have any thoughts on the specific target feature names for
>> module maps I’m proposing (changing “arm” to include AArch64 and adding
>> “arm32”)?  As I’ve said, my own (naive) expectation was that “arm” would
>> include “AArch64”, and I was surprised when that wasn’t the case.
>>> 
>>> I agree, "arm" is the one I was most happy with. What we're doing is
>> based on the ARM ACLE document, which covers both AArch32 and AArch64.
>> The underlying architectures are different, but the whole point of this
>> union (and the modules it's being used to implement) is that the
>> programmer shouldn't have to care. It's also the preferred catch-all
>> term by ARM the company. There's just no viable alternative that I can
>> see for the union.
>>> 
>>> For me, it gets murky when we think about the 32-bit and 64-bit only
>> variants:
>>> 
>>> + arm/arm64 and arm/aarch64 are out because of the top-level choice.
>>> + aarch32/aarch64 would probably be ideal for me, but aarch32 hasn't
>>> really caught on elsewhere  + arm32/arm64 is also possible, especially
>> as Apple are going to be the main consumers.
>> 
>> FWIW, we currently have both “arm64” and “aarch64” for the 64 bit
>> variant, so either or both of “arm32”, “aarch32” would fit.  Maybe we’d
>> be better off with just “aarch32” so that we avoid introducing a name
>> that isn’t really used anywhere else (arm32).
>> 
>> Ben
>> 
>>> 
>>> Anyway, that's my preferred shade of fuschia. Orange spots are also an
>> option.
>>> 
>>> Cheers.
>>> 
>>> Tim.
>> 
>> 
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 
>