> 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.