ARM is pleased to announce a port of GCC to its AArch64 architecture.
Please note that while the compiler has been used to build a large
body of software, it cannot yet be considered complete. We expect
there to be a number of as yet undiscovered bugs and other issues that
will need to be resolved before the code can be integrated into the
main compiler. Nevertheless, we believe that the code is now in a
state where it is worth starting the process of a public review so
that we can address the outstanding issues in time for the GCC-4.8
release.
Perhaps one of the more contentious design issues that we have made is
to produce a compiler that is separate from the existing ARM
compiler. We spent quite a bit of time debating this internally, but
concluded that keeping the sources separate was the correct answer:
- There is no function-call-level compatibility between the AArch64
and AArch32 states; interworking can only occur at the exception
level boundary (eg between user and kernel states).
- The A64 instruction set differs from ARM in several significant ways
- There are more registers
- There is no generalized conditional execution
- Register naming is substantially different
- There is at best only a similarity between the A64 and the
A32 and T32 mnemonics. In particular, although Neon provides
similar functionality, the instructions are very different.
- The floating-point register architecture in AArch64 differs from
that in AArch32.
- The majority of the existing ARM-specific command-line options do
not apply to AArch64; conflating the two would be confusing to users
- Very little code in the port back-end would be directly shared; and
in addition to the maintenance overhead, sharing the code would
create a performance overhead at run time.
- By starting from scratch we've been able to fully utilize some of
the new constructs that GCC now contains.
Perhaps the only area where there is potentially significant
opportunity for sharing is in the pipeline descriptions. However, we
believe that in this case it should be feasible to make use of the
same description in both back-ends.
There are still a number of components that require some further
work. Issues that we are aware of (at a coarse level of granularity)
include:
- Improving the arm_neon.h implementation and auto-vectorization
- Support for languages beyond C, C++ and Fortran
- Atomic optab support
- Further memory and TLS models
- Some of the extended compilation modes, such as profile support,
libmudflap, stack-protector.
Some of these will be much easier to complete if we can openly discuss
the issues with community experts.
The sources can be found in SVN in
svn://gcc.gnu.org/gcc/branches/ARM/aarch64-branch.
This branch will track trunk until such time as the code is merged
into trunk. Patches to this branch should be tagged "[AARCH64]" and
must be approved by ARM personnel.
