Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int.

[Isaku Yamahata]

On Fri, Jul 10, 2009 at 07:55:44AM -0500, Anthony Liguori wrote:
> Isaku Yamahata wrote:
> > Then, the signatures should like the followings?
> >
> > void cpu_out[bwl](CPUState *env, int64_t addr, int{8, 16, 32}_t val);
> > uint{8, 16, 32}_t cpu_inw(CPUState *env, int16_t addr);
> >   
> 
> If anything, it ought to be:
> 
> void cpu_out[bwl](CPUState *env, uint16_t addr, int{8, 16, 32}_t val);
> 
> But it's int today because the assumption is that most architectures can
> more efficiently pass int than other types (because it's the native
> type) and that int is adequate to contain all of the necessary types.
> 
> But my original question still remains, what's the motivation for this
> change?

Yes, the patch description too terse.
The motivation is to remove inconsistency with the other part of
qemu.

- Using int for cpu_{in, out}[bwl] is inconsistent with other part.
  For address or value, uintN_t is used by other qemu part.
  At least I can confirm, softmmu, CPU{Read, Write}MemoryFunc, pci,
  target_phys_addr_t and the callers of cpu_{in, out}[bwl]().

- It is a bad idea to mix signed with unsigned unnecessary.
  So at least unsigned int should be used instead of int.

- (u)int_fastN_t is more appropriate than (u)int.
  It is claimed that int is used for optimization assuming that
  sizeof(int or uint) >= sizeof(uint32_t).
  (u)int_fast32_t is more appropriate than (u)int with such a assumption.
  The other part of qemu like softmmu which is much more performance
  critical uses uint32_t.


So what do you think?
I'll add more patch description and update/send the patch
with whatever types we agree on. (or leave it as int)

Thanks,
-- 
yamahata