Could we agree to disagree and come together on improvements andclean-up?
arndt at jjj.de
Mon Jun 2 09:00:25 CEST 2008
* Vincent Lefevre <vincent at vinc17.org> [Jun 02. 2008 16:17]:
> 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.
Most code doesn't, yes. But: are we using bit-count anywhere? I
would have a hard time to code bit-count so that it works on all
allowed models. It may not even be well-defined on all models!
Look into Knuth's new text on bit-fiddling, "Hacker delight", or
the first chapter of http://www.jjj.de/fxt/fxtpage.html#fxtbook
There are strong assumptions about the model used.
> > 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)?
Would you expect to see such CPU? Even if so, would there likely
be a GMP port?
> > - 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.
As soon as your code depends on internal byte ordering, it depends
on the exact ordering! Cf. /usr/include/endian.h
#define __LITTLE_ENDIAN 1234
#define __BIG_ENDIAN 4321
#define __PDP_ENDIAN 3412
> > - two's complement,
> > - no exception on integer overflow,
> In general, that's not necessary.
Yes, but I dare to say that a lot of code will break if you
compile it on ones complement. I guess almost all code that
for some reason is "bit-aware" will break.
> 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
> this guarantee.
I could easily adapt e.g. my low-level code for that. Still I'd have
to make own branches for, say, long=43-bit, long=27-bit etc.
I could create a branch that will work for all sizes, but it will be
> 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.
But I argue that using intptr_t etc. as suggested may be OK but will
NOT magically make everything work on just any model!
> 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