Could we agree to disagree and come together on improvements andclean-up?
vincent at vinc17.org
Mon Jun 2 11:00:22 CEST 2008
On 2008-06-02 17:00:25 +1000, Joerg Arndt wrote:
> 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!
I disagree. In general, bit counts really make sense only on
non-negative values (does GMP purposely use bit counts on values
that can be negative[*]?), in which case the bitcount function
prototype can use an unsigned type, and the model for signed
values no longer matters.
[*] Both count_leading_zeros() and count_trailing_zeros() use
an unsigned type, so I doubt it.
> 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.
I can see that examples use an unsigned long (I haven't checked
everything though). So, this does not depend on the model.
> > 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?
Strangest CPUs have been seen in the past. And some CPUs such as DSPs
have particular features.
> Even if so, would there likely be a GMP port?
A GMP port could be useful.
> > > - 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
Yes, but I mean that you already have the code to deal with that.
In general, there is no need for big changes to support other
> > > - 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.
This was mainly for the "no exception on integer overflow", for which
badly-written code *already* breaks; see e.g.
And see at the beginning of this mail for two's complement.
> > > - 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
No, you can use types like int64_t and require that the C implementation
supports them. Even if long is, say, on 48 bits, a C implementation
could still define a 64-bit type with int64_t and support it. This is
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