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

[Joerg Arndt]

Hi everybody,

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

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

Yes!

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)

cheers,   jj