qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/9] exec: add endian specific phys ld/st functi


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 1/9] exec: add endian specific phys ld/st functions
Date: Wed, 6 Jul 2011 15:18:01 +0200

Am 06.07.2011 um 15:03 schrieb Hannes Reinecke <address@hidden>:

> On 07/06/2011 01:34 PM, Alexander Graf wrote:
>> 
>> 
>> 
>> 
>> On 06.07.2011, at 12:24, Paolo Bonzini<address@hidden>  wrote:
>> 
>>>> diff --git a/exec.c b/exec.c
>>>> index 5f2f87e..f281ba4 100644
>>>> --- a/exec.c
>>>> +++ b/exec.c
>>>> @@ -4127,7 +4127,8 @@ void cpu_physical_memory_unmap(void *buffer, 
>>>> target_phys_addr_t len,
>>>>  }
>>>> 
>>>>  /* warning: addr must be aligned */
>>>> -uint32_t ldl_phys(target_phys_addr_t addr)
>>>> +static inline uint32_t ldl_phys_internal(target_phys_addr_t addr,
>>>> +                                         enum device_endian endian)
>>> 
>>> You probably need the __always_inline__ attribute to really convince GCC to 
>>> inline this.
>> 
>> There's a define in osdep.h that converts inline into always_inline :)
>> 
> Btw, while you're at it:
> 
> uint32_t ldub_phys(target_phys_addr_t addr);
> uint32_t lduw_phys(target_phys_addr_t addr);
> 
> Hmm? ldub is supposed to read an 'unsigned byte' (uint8_t),
> and lduw is supposed to read an 'unsigned word' (uint16_t).
> 
> Why does it return an uint32_t?

Because it ends up being a 32-bit register for the return value / parameter 
anyways :).

But this is a different thing. I'd prefer to  focus on the endian problem for 
now.


Alex




reply via email to

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