array of bits

[Eric Sosman]

[...]
I think that nearly boils down to "64-bit machines have 64-bit machine
words, and 32-bit machines have 32-bit machine words". All that remains
is to define "machine word".

Which you've more or less already done: a machine word can be accessed
by a single instruction. But there's no portable way to detect that in
C.

Even that much starts to get fuzzy around the edges. For
example, SPARC is an architecture with 64-bit CPU registers, but
numeric constants in "immediate" instructions are limited to 22
bits (maybe less, depending on the instruction). So, the O.P.
may say "Aha! 64-bit registers and 64-bit memory accesses and I'm
off to the races!" only to discover that some of his masks and
suchlike constants require multiple instructions or multiple memory
accesses ...

... but we're all guessing, anyhow. Let's wait for "" himself
to tell us what he means -- and why he cares.

 

[Malcolm McLean]

How can I know which is the natural word size of the machine and do
all the rest?

Take the size of a pointer. It's not infallible, but almost always
address buses and data buses are the same width, so that at a low
level machine addresses can be read or written as data in one write.
If CHAR_BIT is 8, which it virtually always is, and sizeof (int *) is
8, you've got a 64 bit machine. Howwever the 64-bt type may be long or
long long.

The campaign for 64 bit ints is trying to change this situation and
make the normal 64 bit type on 64 bit machines int. However so far we
haven't had much success in getting our people onto the committee.
Maybe we need a coalition with the anti-restrict crowd, who are our
natural allies.

 

[bart.c]

Take the size of a pointer. It's not infallible, but almost always
address buses and data buses are the same width,

The few times I've needed to know address and data bus widths, they were
always different.

so that at a low

level machine addresses can be read or written as data in one write.
If CHAR_BIT is 8, which it virtually always is, and sizeof (int *) is
8, you've got a 64 bit machine.

I don't know if that follows; a machine may use 32-bit addressing, and use
another 8-32 bits for other purposes.

The campaign for 64 bit ints is trying to change this situation and
make the normal 64 bit type on 64 bit machines int. However so far we
haven't had much success in getting our people onto the committee.
Maybe we need a coalition with the anti-restrict crowd, who are our
natural allies.

If I had to estimate, I would say that 80% of my int values would fit into
8-bits, 90% into 16-bits, and perhaps 99% into 32-bits. So I should be
forced to always use 64-bits just for that remaining 1%?

 

[Ersek, Laszlo]

On Fri, 14 May 2010, bart.c wrote:

Malcolm McLean wrote:

[...]

If I had to estimate, I would say that 80% of my int values would fit
into 8-bits, 90% into 16-bits, and perhaps 99% into 32-bits. So I should
be forced to always use 64-bits just for that remaining 1%?

Agreed. I'm convinced the integer promotions are standardized as a
specific concept because they describe or correspond to specific machine
actions on sensible platforms (ie. widening to a minimum register size for
use with arithmetic instructions and the like). If a platform is capable
to handle individual 32-bit ints just as naturally and fast as 64-bit
ints, I definitely wouldn't want a 64-bit type as the target of the
integer promotions. I'd want the narrowest representation that the machine
can use directly (= with no penalties) for arithmetic.

We already have uint_least64_t and uint_fast64_t, both required types.
What's the reasoning behind ILP64? Why is sizeof(int) == sizeof(long) &&
sizeof(long) == sizeof(void *) that important? ILP64 forces the standard
types "int", "long" and "long long" to a common representation, while
digging a ditch between "short" and "int" (or "char" and "short").

I can imagine that heaps of code exist that rely on the interchangeablity
of these three types. I'll risk to claim that such code is undefensibly
sloppy and non-defensive, future un-proof. Even with C89 and nothing else
in mind (which defines no intptr_t yet), code written specifically for a
32-bit machine could have used:

- functions taking a union packing a "void *" and an "int",
- functions taking "long" instead of "int" (LP64 doesn't break those)
- functions taking "ptrdiff_t" / "size_t" instead of "int" /
"unsigned" (ditto).

Cheers,
lacos

 

[William Hughes]

The campaign for 64 bit ints is trying to change this situation and
make the normal 64 bit type on 64 bit machines int. However so far we
haven't had much success in getting our people onto the committee.
Maybe we need a coalition with the anti-restrict crowd, who are our
natural allies.

OK, I'll bite. Why are the anti-restrict crowd your natural
allies.
- William Hughes

Note that I have given this 30 seconds of thought and have
decided the anti-restrict position is nonsense.

 

[\\]

You're wrong.

Yes, mmhhhh.
Perhaps __LP64__, _LP64 (on gcc) is the answer.

 

[Richard Bos]

Wow, it seems that C99 provides something that could help me
(quoted from libc manual):



Tell me if I'm wrong.

You're wrong. Those types are the largest that are available _at all_,
not the largest available in a single machine instruction. There is
nothing in the Standard that lets you decide whether any type is natural
or emulated, and in many implementations, int64_t is emulated.

If you want to continue on the route you're going on, what you need is
probably a typedef to either int_fast32_t or int_fast64_t, a set of
other macros for the various limits, and a compile-time #define that
manually lets you decide which to use. Something like:

#include <stdint.h>
#ifdef 64BITS
#define bitset_t int_fast64_t
#define BITSETMAXBIT 63
#define perhaps some other limits
#else
#define bitset_t int_fast32_t
#define BITSETMAXBIT 31
#define perhaps some other limits
#endif

Richard

 

[Ben Bacarisse]

If you want to continue on the route you're going on, what you need is
probably a typedef to either int_fast32_t or int_fast64_t, a set of
other macros for the various limits, and a compile-time #define that
manually lets you decide which to use. Something like:

#include <stdint.h>
#ifdef 64BITS
#define bitset_t int_fast64_t
#define BITSETMAXBIT 63
#define perhaps some other limits
#else
#define bitset_t int_fast32_t
#define BITSETMAXBIT 31
#define perhaps some other limits
#endif

Why suggest a signed type over an unsigned one? I can't see any
advantages.

 

[Richard Bos]

Take the size of a pointer. It's not infallible, but almost always
address buses and data buses are the same width,

This is both wrong and dumb.

The campaign for 64 bit ints is

....both wrong and dumb. And paranoid.

Richard

 

[\\]

Thank you all.
I think I should put some preprocessor conditional
to detect arch and typedef consequently.

 

[Keith Thompson]

Thank you all.
I think I should put some preprocessor conditional
to detect arch and typedef consequently.

As I wrote before, I think you should first write the code so it
*doesn't care* which type it's using, and test it with various types
from unsigned char up to uintmax_t. Use a typedef so that you only
have to change one line of code to change the underlying type.
Once you've got the code working, measure its performance with
various types. Then, and only then, think about how to select the
type automatically to get the best performance on various systems.

Don't assume that one type will be faster than another until you've
measured it.

 

[Richard Bos]

Why suggest a signed type over an unsigned one?

Pure and simple daft moment on my part. I did intend to use unsigned
ints; I even considered adding a note that of course, for this purpose,
the unsigned types are preferable to the signed ones; the MAXBIT defines
are correct for the unsigned types, and wrong for the signed ones; and
then, with my brain apparently running on 50%, I used the signed types.

So yes, use uint_fast64_t and uint_fast32_t instead.

Richard