On Fri, 15 Jun 2012, Mike Stump wrote: > On Jun 15, 2012, at 2:46 PM, Joseph S. Myers wrote: > > HOST_WIDE_INT is an abstraction about the *target*; the target determines > > the required properties. The salient properties include: > > > > * At least as wide as target address space. > > The first person to do a 128 bit address support isn't going to > appreciate all the work they are going to have to do. With some luck, > before then, we will have switched to C++ and engineered in some > prettier interfaces that will just work with no changes. Today, it > would be a major pain.
Well, you'll want 128-bit HOST_WIDE_INT to manipulate object sizes etc. for a 128-bit target. Say the compiler used for the host is GCC. If the host is 64-bit, you have __int128 and unsigned __int128 available (with older GCC, __int128_t and __uint128_t). There are just a couple of problems with those types, one a technical standards issue and one more serious as a practical issue: * They are sui generic types that act quite like integer types but aren't actually integer types, because of the host ABI defining intmax_t as 64-bit. * They lack any printf support (at least with glibc), and such support is needed by GCC for HOST_WIDE_INT. Given control over the host C library, both issues could be addressed by changing intmax_t on the host to 128 bits - printf %j formats would then be appropriate for 128-bit types. (You'd need a host GCC change as well to define an integer constant suffix for 128-bit constants.) That certainly ought to be practical in glibc with symbol versioning if desired - no worse than the way various architectures moved to 128-bit long double. You'd probably also find places in GCC that assume that HOST_WIDE_INT is either 32-bit or 64-bit, but I expect it would be straightforward to adjust those to support 128-bit as well. True, C++ may make it possible to use something other than a built-in integer-like type of the host compiler, but I don't think that's needed for this. (I'm not particularly concerned about 32-bit host support for this hypothetical 128-bit target; anyway, it should be practical to support __int128 for 32-bit systems, with some work on the libgcc side of things.) > > * Constants for the target can be represented in at most two > > HOST_WIDE_INT. > > This is nice in theory but no longer true for some of us. :-( This could also reasonably be cleaned up separately from other uses of HOST_WIDE_INT. Maybe what's really wanted is some abstraction for wide target constants - which usually would be much like double-int.[ch], but for targets that need it would be larger. Certainly the const_int / const_double division - where const_double represents *either* wide integers *or* floating-point constants - is an ugly interface, and it would be better for integers of whatever size to be const_int and const_double only to be floating point. -- Joseph S. Myers jos...@codesourcery.com