qemu-riscv
[Top][All Lists]
Advanced

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

Re: [Qemu-riscv] [Qemu-devel] [PATCH v4 02/15] memory: Access MemoryRegi


From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-riscv] [Qemu-devel] [PATCH v4 02/15] memory: Access MemoryRegion with MemOp
Date: Fri, 26 Jul 2019 08:10:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

On 7/26/19 8:03 AM, address@hidden wrote:
> On 7/25/19 9:45 PM, Philippe Mathieu-Daudé wrote: 
>>On 7/25/19 11:52 AM, address@hidden wrote:
>>> Replacing size with size+sign+endianness (MemOp) will enable us to
>>> collapse the two byte swaps, adjust_endianness and handle_bswap, along
>>> the I/O path.
>>> 
>>> While interfaces are converted, callers will have existing unsigned
>>> size coerced into a MemOp, and the callee will use this MemOp as an
>>> unsigned size.
>>> 
>>> Signed-off-by: Tony Nguyen <address@hidden>
>>> ---
>>>  include/exec/memop.h  | 4 ++++
>>>  include/exec/memory.h | 9 +++++----
>>>  memory.c              | 7 +++++--
>>>  3 files changed, 14 insertions(+), 6 deletions(-)
>>> 
>>> diff --git a/include/exec/memop.h b/include/exec/memop.h
>>> index ac58066..09c8d20 100644
>>> --- a/include/exec/memop.h
>>> +++ b/include/exec/memop.h
>>> @@ -106,4 +106,8 @@ typedef enum MemOp {
>>>      MO_SSIZE = MO_SIZE | MO_SIGN,
>>>  } MemOp;
>>> 
>>> +/* No-op while memory_region_dispatch_[read|write] is converted to
> MemOp */
>>> +#define MEMOP_SIZE(op)  (op)    /* MemOp to size.  */
>>> +#define SIZE_MEMOP(ul)  (ul)    /* Size to MemOp.  */
>>
>>SIZE_MEMOP() is never used until patch #10 "memory: Access MemoryRegion
>>with MemOp semantics", it would be clearer to only introduce the
>>MEMOP_SIZE() no-op here, and directly introduce the correct SIZE_MEMOP()
>>macro in patch #10.
> 
> SIZE_MEMOP() is used, and is the main change, in patches #3 to #10.
> Perhaps you
> meant MEMOP_SIZE()?

Eh, I inverted the macro names... :( Thanks for correcting me.

> Either way, you have raised an issue :)
> 
> There is a lack of clarity in how the two macros are used to update the
> interfaces.​
> 
> 



reply via email to

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