[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfe-dev
Subject:    Re: [cfe-dev] [RFC] Make "requires arm" also include AArch64 in module map files
From:       "Kristof Beyls" <kristof.beyls () arm ! com>
Date:       2015-07-29 17:31:30
Message-ID: 001601d0ca24$685e0550$391a0ff0$ () arm ! com
[Download RAW message or body]

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@cs.uiuc.edu [mailto:cfe-dev-bounces@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@apple.com>
> wrote:
> > 
> > On 28 Jul 2015, at 06:32, Ben Langmuir <blangmuir@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@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic