Subject: Re: ARM ELF toolchain patches
To: Ben Harris <bjh21@netbsd.org>
From: Richard Earnshaw <rearnsha@buzzard.freeserve.co.uk>
List: port-arm32
Date: 02/21/2001 23:55:15
> On Wed, 21 Feb 2001, Charles M. Hannum wrote:
>
> > On Wed, Feb 21, 2001 at 07:10:29PM +0000, Ben Harris wrote:
> > >
> > > If people want to make any more changes to the ABI (8-byte alignment of
> > > int64_t?), now's the time to mention it.
> >
> > Are you, or are you not, using the same ABI that ARM Ltd. and/or Linux
> > are using?
>
> I honestly don't know. This is part of why I put in that sentence.
Adding support for 8-byte alignment for int64_t would definitely improve
performance on XScale/ARM10 generation processors, which have 64-bit data
paths to memory. However, I don't think transitioning to this is trivial,
which is why I've shied away from proposing it. In particular the issues
related to stack alignment are quite tricky (many instructions, including
some of the new VFP instructions push an odd number of words onto the
stack and are inteded to be used with base-register write-back). This
isn't a major problem if momentary stack unalignemnt is OK, but issues
such as asynchronous events have to be considered (for example, if a
signal were received when the stack was not 8-byte aligned, would the
signal handler function correctly -- in particular, would it run on its
own stack, or on the stack of the current process?).
Without knowning the answers to questions such as this, the impact of
ensuring 8-byte alignment is hard to estimate.
(fixing gcc to ensure that the stack were at all times 8-byte aligned
would be a non-trivial exercise, and may impact performance on some
machines quite noticeably).
8-byte alignment of the stack is required by the ATPCS, however, it does
not specify that the stack should at all times remain strictly aligned (in
effect, the only requirement is that when control passes from one function
to another the stack is 8-byte aligned -- at other times, it is up to the
implementation).
It probably would be a good thing to make malloc() and friends always
allocate 8-byte aligned memory, the cost of doing this will probably be
sufficiently low that it would be unconditionally good -- does this
require compiler support? I will investigate the issues of ensuring
minimally conforming stack alignment.
> At the moment, we mostly follow GCC's defaults, with the only significant
> difference being our use of VFP-format doubles rather than FPA-format.
> This probably makes us different from Linux. I've no idea how we differ
> from ARM's view of the world.
Linux still uses FPA format numbers -- I've no idea when they will change.
They also use FPA isntructions -- since we currently don't support the
FPA chips, I'm not even sure if such code would function correctly on
ARM7500 machines until this was added.
Richard.