[Top][All Lists]
[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