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