Could we agree to disagree and come together on improvements andclean-up?
vincent at vinc17.org
Sun Jun 1 21:43:50 CEST 2008
On 2008-06-01 21:02:08 +1000, Joerg Arndt wrote:
> However, taking care of everything allowed by the standard is IMHO
> unwise. For one example, ones complement, I'd be surprised if more
> than 1 percent of all existing code would do what it's meant to do
> when compiled on a ones-complement environment.
I agree for one's complement, but I'd say that most code doesn't need
to assume two's complement.
> Roughly, the code should work on what I call a sane arch/model:
> - long is machine word,
No, long should just fit the needs. What if a processor has 32-bit
words and use pointers on 64 bits (two words)?
> - byte order is little- or big- endian (not 1342 or such),
In general, if one supports both little- and big-endian, one doesn't
need to assume more.
> - two's complement,
> - no exception on integer overflow,
In general, that's not necessary. Not assuming wrapping is sufficient,
and also *necessary* in practice because of optimizations (now you can
still write code for gcc and use -fwrap if you want to assume wrapping).
> - bits per int/long is a power of two
On some platforms, this isn't the case, for good reasons. And it isn't
necessary assume a power of two. C99 already provides types that offer
BTW, you forgot GPUs that don't even have a conventional processing
model. And it is much harder to write code for GPUs than for machines
with one's complement, mixed-endian and so on.
Vincent Lefèvre <vincent at vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
More information about the gmp-discuss