[aarch64-port-dev ] VAR_CPU_ARCH for ARM platforms

Edward Nevill edward.nevill at gmail.com
Thu Dec 24 12:27:54 UTC 2015


On Wed, 2015-12-23 at 23:43 +0000, Andrew Haley wrote:
> On 23/12/15 20:36, Bob Vandette wrote:
> >> > This is not true of x86_64, which is a rather elaborate 64-bit
> >> > extension of x86.
...
> > One could say the same thing about armv8 versus armv7.
> [ NB: ARMv8 identifies both the AArch32 and AArch64 instruction set
> architectures.  AArch32 is a slightly extended ARM; AArch64 is all-
> new. ]
> 
> > That really depends on your criteria for comparison.  I still
> > believe we need a broad variable that identifies ARM varieties.
....
> > Without this, when the aarch32 port is attempted there’s going to be
> > a lot of extraneous checks required in the makefile for “if ARCH ==
> > aarch32” || ARCH == arm in places that would not need to be changed
> > simply because we didn’t use the existing variable for the purpose
> > that I believe it was originally intended.
> 
> I totally agree about AArch32 and ARM.  It's the same thing: the
> AArch32 project is just about creating ARM-open.  There definitely
> should be a variable to cover those.

FWIW the aarch32 port does

-DAARCH32 -DARM

in its sysdefs. The rationale for adding -DAARCH32 is to avoid conflicts
with the proprietary port.

My 2c worth is that aarch64 should be considered a completely separate
port. It is not like x86/x86_64. You cannot access the 32 bit
instructions from aarch34. In fact some implementations do not even have
the 32 bit instructions, ie they are pure aarch64.

wrt the differences between armv7 and aarch32 they are not worth
considering as separate, they are only a few mcr instructions to do with
cache flushing/barriers and are deprecated in armv7 in any case. The
correct fix is to use the non deprecated instructions in armv7 which
will then also work on aarch32.

All the best,
Ed.




More information about the aarch64-port-dev mailing list