Re: Natural size: int

"Frederick Gotham" <fgothamNO@xxxxxxxx> wrote in message
news:fk6Cg.12408$j7.321473@xxxxxxxxxxxxxxxxx
Stephen Sprunk posted:


Or perhaps should "short" be 32-Bit? Or should "char" become
16-Bit
(i.e. 16 == CHAR_BIT).

A char should be the smallest addressable unit of memory; if your
system only supports 16-bit (or greater) loads, it may be
reasonable
to have CHAR_BIT==16, but expect to have to hack up virtually every
program you try to port. Even Cray and the DEC Alpha had to
synthesize 8-bit loads for the char type, because not doing so was
suicide.


I don't see why (unless you're reading/writing data to/from disk
perhaps?).


Another semi-related question:

If we have a variable which shall store the quantity of
elements
in an
array, then should we use "size_t"? On a system where "size_t"
maps
to "long unsigned" rather than "int unsigned", it would seem to be
inefficient most of the time.

You assume that shorter ints are somehow more efficient than longer
ints; many modern processors have slow shorts and int is no faster
than long or long long.

No, I presume that int is faster than long (or they're both as fast
as each
other).

I would expect the following:

speed_of(int) >= speed_of(long)

True in every implementation I've seen; int is typically chosen to be
the fastest size that the platform supports (of at least 16 bits).
However, there is no guarantee that the designers of a particular
implementation possess common sense.

speed_of(int) >= speed_of(short) >= speed_of(char)

Not always true. shorts are slower than chars even on some common
platforms (e.g. Intel P6-based cores), and chars may be faster than
ints and shorts due to reduced memory pressure.

I would expect ints to be faster than shorts or chars in most
situations, but it's possible that memory effects may make chars
faster for particular tasks.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking



--
Posted via a free Usenet account from http://www.teranews.com

.

Relevant Pages

  • Re: Malcolms new book
    ... buffer (ints being too small) but *can* accept negative values. ... support for perfectly legitimate buffers. ... But that's not what he said; he said you can't pass chars to the ...
    (comp.lang.c)
  • Re: problem with binary file
    ... Chars are (very short ints). ... Even shorter than shorts. ...
    (comp.os.linux.development.system)
  • Re: What is this?
    ... Hence everything is 4-bytes: chars, ints, longs, floats... ...
    (comp.lang.c)
  • Re: va_start problem
    ... All the arguments are ints. ... if the chars are always promoted to int in variadic function then why there's va_arg? ... I knew that integer promotions in variadic functions.. ...
    (comp.lang.c)
  • Re: liitle endian
    ... // little endian ... System has 16-bit chars, 16-bit shorts, 32-bit ints, and is ...
    (comp.lang.c)