Patrick Welche wrote:
> On Mon, Dec 11, 2006 at 08:34:17AM -0800, Charles L. Nelson wrote:
> > I think that on some systems it is possible to tell the compiler to use
> > 32-bit addresses and pointers while ints are 32-bits and longs are 64-bits.
> > This is the default ABI on many 64-bit machines unless it is overridden.
> > 
> > Also, there are only a few 64-bit architectures that can make use of true
> > 64-bit addressing.  While the compiler may allow 64-scalar addressing in the
> > source code, somewhere in the build process, the address is usually munged
> > down to the size of the MMU quantum which can be 36-bit, 40-bit or 56-bit
> > depending on architecture.
> 
> So going further off-topic - what is the size of a "word"? I think it is
> the same as sizeof(void *) so I would get 64, but should I get 36/40/56 ?

The C standards do not know the term "word" and the sizeof operator tells you
very little about the number of bits. ISO C99 has UINTPTR_MAX but I wouldn't
recommend trying to derive more information from it than it's meant to provide.
For example, on NetBSD it's the equivalent of "(uint64_t) -1" albeit the
current AMD64 CPUs do not support a 64-bit address space.

It's also very common - though strictly undefined by C - to carry longs in
pointers and vice-versa, so if you tried to cram them into 5 or 6 bytes because
you know your hardware, you might experience some nasty surprises.  Note that
nobody prevents you to use any arbitrary amount of bytes to store indices. If
an 16-bit integer is insufficient, but 32-bit is overkill and you're more
worried about memory space/bandwidth than CPU cycles you can always portably
use 3 bytes to store a 24-bit value.

-- 
Christian