Paul> Main question I have for you guys is to understand in the case
Paul> of the PPC what the extra effort would be if we had to use the
Paul> PPC Linux as apposed to EABI compiler?
>>  I think we concluded last week this would make no difference. We
>> already use a PPC Linux compiler for eCos PPC boards in the farm
>> right now, apparently.
>> 
>> But we'd want to check the ABI differences and make sure. If there
>> are any changes, the code could be fixed in a matter of minutes.

Paul> Nick seemed to have an about turn and think this could
Paul> potentially be pretty far reaching - especially the MIPS arch -
Paul> v.different ABI due to PIC/PID, etc?

Paul> Pls check PPC Linux compiler usage...

I've looked at the PPC EABI which is an extension of the SVR4
ABI. There are no changes to use of registers in calls.

In SVR4 the stack pointer must always be 16-byte aligned, while in the
EABI it only needs to be 8-byte aligned. I believe we may actually
leave it only 4-byte aligned in some situations, so that would need
fixing (and according to the ABI in effect).

There are similar alignment differences for aggregate and long data
types, so we (I) should double check the linker script alignment
statements. 

Finally, we don't initialize GPR13 as required by both ABIs, and I
suspect the linker script also botches on the definition of the symbol
used for initializing GPR2 which is a requirement in the EABI.  Again,
something that needs to be cleaned up and made dynamic based on the
ABI in effect.

I'm opening a bug on these issues.

Jesper