On Mon, Jun 29, 2015 at 03:46:54PM +0200, Gerd Hoffmann wrote: > On Mo, 2015-06-29 at 09:02 -0400, Kevin O'Connor wrote: > > On Mon, Jun 29, 2015 at 10:53:29AM +0200, Gerd Hoffmann wrote: > > > Add macros to read/write registers of virtio-1.0 regions. > > > > > > Signed-off-by: Gerd Hoffmann <kra...@redhat.com> > > > --- > > > src/hw/virtio-pci.h | 76 > > > +++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > 1 file changed, 76 insertions(+) > > > > > > diff --git a/src/hw/virtio-pci.h b/src/hw/virtio-pci.h > > > index 893a7dd..e1d8b3e 100644 > > > --- a/src/hw/virtio-pci.h > > > +++ b/src/hw/virtio-pci.h > > > @@ -111,6 +111,82 @@ struct vp_device { > > > struct vp_cap common, notify, isr, device; > > > }; > > > > > > +#define vp_modern_read(_cap, _struct, _field, _var) { \ > > > + u32 addr = _cap.addr; \ > > > + addr += offsetof(_struct, _field); \ > > > > Wouldn't this make more sense if the bulk of the code was in a > > function? > > The idea is that 'sizeof((_struct *)0)->_field)' evaluates to a > compile-time constant, so gcc can optimize away the bulk of the #define.
Would it matter though? Are any of these accesses performance sensitive? Also, if "_vp_modern_read()" was marked as inline wouldn't gcc ultimately produce the same thing? > Also we don't have to use u64 for _var then (except when it actually is > a 64bit value). > > But having 'vp_modern_read(..., var)' in the code instead of 'var = > vp_modern_read(...)' isn't that nice indeed. Hrmm. That's an interesting question - how well would gcc do if _vp_modern_read() was inline'd and returned a 64bit value that was then immediately truncated in the majority of cases. -Kevin