Could we agree to disagree and come together on improvements andclean-up?

[Vincent Lefevre]

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
orderings.

> > > - 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.

  http://gcc.gnu.org/ml/gcc/2008-04/threads.html#00115

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
> slow.

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
cleaner.

-- 
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)