Re: [Qemu-devel] [PATCH] Memory API bugfix - abolish addrrrange_end()

[David Gibson <david@gibson.dropbear.id.au>]

On Sun, Oct 16, 2011 at 02:35:37PM +0200, Avi Kivity wrote:
> On 10/16/2011 01:40 PM, David Gibson wrote:
> > > Let me see if I can work up a synthetic int128 type.
> >
> > So.. you think replacing every single basic arithmetic operations with
> > calls to implement the synthetic type, _and_ imposing the resulting
> > overhead is _less_ ugly than some slightly fiddly re-ordering of
> > operations?  Seriously?
> >
> 
> In terms of how the code looks, it's seriously more ugly (see the
> patches I sent out).  Conceptually it's cleaner, since we're not dodging
> the issue that we need to deal with a full 64-bit domain.

We don't have to dodge that issue.  I know how to remove the
requirement for intermediate negative values, I just haven't made up a
patch yet.  With that we can change to uint64 and cover the full 64
bit range.  In fact I think I can make it so that size==0 represents
size=2^64 and even handle the full 64-bit, inclusive range properly.

> But my main concern is maintainability.  The 64-bit blanket is to short,
> if we keep pulling it in various directions we'll just expose ourselves
> in new ways.

Nonsense, dealing with full X-bit range calculations in X-bit types is
a fairly standard problem.  The kernel does it in VMA handling for
one.  It just requires thinking about overflow cases.

> The overhead is negligible.  This code comes nowhere near any fast path.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson