qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/2] linux-user: ppc: mark as long long aligned


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 1/2] linux-user: ppc: mark as long long aligned
Date: Mon, 1 Oct 2012 15:10:05 +0200

On 01.10.2012, at 15:04, Andreas Färber wrote:

> Am 30.09.2012 03:32, schrieb Alexander Graf:
>> The PPC32 ABI dictates that long long (64bit) parameters are pass in odd/even
>> register pairs. Because unlike ARM and MIPS we start at an odd register 
>> number,
>> we can reuse the same aligning code that ARM and MIPS use.
>> 
>> Signed-off-by: Alexander Graf <address@hidden>
>> ---
>> linux-user/syscall.c |    6 +++++-
>> 1 files changed, 5 insertions(+), 1 deletions(-)
>> 
>> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
>> index 1a38169..8cd56f2 100644
>> --- a/linux-user/syscall.c
>> +++ b/linux-user/syscall.c
>> @@ -587,12 +587,16 @@ extern int setfsgid(int);
>> extern int setgroups(int, gid_t *);
>> 
>> /* ARM EABI and MIPS expect 64bit types aligned even on pairs or registers */
>> -#ifdef TARGET_ARM 
>> +#ifdef TARGET_ARM
> 
> For anyone wondering, this is dropping a whitespace at end of line. ;)

Yeah, my vi scripts marked it as red, which always makes me nervous :).

> 
>> static inline int regpairs_aligned(void *cpu_env) {
>>     return ((((CPUARMState *)cpu_env)->eabi) == 1) ;
>> }
>> #elif defined(TARGET_MIPS)
>> static inline int regpairs_aligned(void *cpu_env) { return 1; }
>> +#elif defined(TARGET_PPC) && !defined(TARGET_PPC64)
>> +/* PPC32 expects 64bit parameters to be passed on odd/even pairs of 
>> registers
>> +   which translates to the same as ARM/MIPS, because we start with r3 as 
>> arg1 */
>> +static inline int regpairs_aligned(void *cpu_env) { return 1; }
>> #else
>> static inline int regpairs_aligned(void *cpu_env) { return 0; }
>> #endif
> 
> It is obvious that this function has been copied unmodified from mips,
> but shouldn't new code use bool and true, assuming that there is no
> magic performed on the return value? :)

The asm result should be the same, since they're all getting inlined, no? And 
it wouldn't tremendously increase readability either. So for now, I'd say either

  a) send a separate cleanup patch

or

  b) leave it as is :)


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]