[U-Boot] RFC: Aligning arch initialisation sequences

[Albert ARIBAUD <albert.aribaud@free.fr>]

Le 14/11/2010 11:30, Wolfgang Denk a ?crit :
> Dear Albert ARIBAUD,
>
> In message<4CDFA8E9.3050803@free.fr>  you wrote:
>>
>>> Is there any reason the other arches could not implement an inline function
>>> as well? ARM for example:
>>>
>>> -#define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm ("r8")
>>
>> There is no way to set aside a register in ARM code for applicative
>> purposes.
>
> What exactly do you mean by that?

Use of the 16 ARM registers r0 to r15 in C code is governed by ABIs; we 
use the one known as (GNU) EABI. The compiler will both respect this ABI 
when generating code and assume it is respected by any other code in the 
application.

The GNU EABI is based on the AAPCS which defines the use of registers. 
r0 to r3 are used for call parameters;  r4 to r8, r10 and r11 are used 
as local variables; r12 is a scratch register; r13, r14 and 15 are the 
stack pointer, return address holder and program counter respectively. 
None of these registers can be used as a global constant except r9, 
which is indicated as 'plaform-specific' and potentially useable by 
variants of the AAPCS.

One could argue that using r9 to locage GD would constitue such a 
variant, platform-specific use of AAPCS. However, some -gcc) compiler 
switches actually cause the generated code to follow such variants of 
AAPCS and use r9 for specific purposes (some even r10 if r9 is used, 
even though this is not strictly AAPCS compliant) -- and I don't know 
about potential uses by other compilers.

I would thus not favor using r9 for gd access if there is another way.

Amicalement,
-- 
Albert.