Storage of char in 64 bit machine

[aruna.mysore]

Hi all,

I have a simple definitioin in a C file something like this.

main()
{
char a;
.......
int k;
}

Since character is 8 bit, how is it stored in the machine in a 64 bit
machine. If it is word aligned, what about the rest of the bytes. What
about the retrievel of the char c, will it be expensive. Is it
expensive w.r.t read or write.

Thanx and Regards,
Aruna

[Mikhail Teterin]

Jack Klein wrote:

Almost every single DSP in existence, for starters.

When a concept of "currency" becomes applicable to a DSP, I may accept this
example... I was, of course, talking about general-purpose computers...

I routinely work on a TI DSP these days where CHAR_BIT is 16 and
sizeof(int) is 1.

This is interesting -- why is this a char, and not, say, a short then? Is
there an 8-bit type at all?

-mi

[Mikhail Teterin]

Eric Sosman wrote:

As one can admire the skills of the buggy whip makers and the
inordinate amount of labor they would expend on a single whip, so
one can admire the "cool tricks" of the programmer-craftsmen and
their perseverance

The major difference between the relationship of a buggy whip maker and a
car vs. that of an old-time programmer and a modern computer -- the
difference that pretty much destroys your entire analogy -- is that a car
will not run any faster, when whipped.

A well-crafted program, however, _will_ run faster on a modern computer.

The vast speed and memory-amounts improvements of modern computers are
supposed to enable them to run programs better -- not to allow the
programmers to be sloppier.

I'm not pushing *you* to write as efficient programs as you did, when
you "lived in the cage". But don't stop *me* from trying to keep my
programs runnable on that ancient hardware -- even if they'll never see it.

Running on a DSP (where CHAR_BITS is 16) is not a valid argument. The only
sound one s that a compiler can do a better job. But I doubt, it can --
I'll verify and post the results...

Yours,

-mi

[Frederick Gotham]

Mikhail Teterin posted:

>I routinely work on a TI DSP these days where CHAR_BIT is 16 and
sizeof(int) is 1.

This is interesting -- why is this a char, and not, say, a short then? Is
there an 8-bit type at all?

Define "8-Bit type". Do you mean 8 object representation bits, or 8 value
representation bits?

If you mean object representation bits, then there can't be (unless there's a
type which is provided as an extension).

If CHAR_BIT is 16, then all of the three "char" types must have 16 object
representation bits.

--

Frederick Gotham

[Mikhail Teterin]

Stephen Sprunk wrote:

The implementation is likely to have a very, very clever strcmp() that
will perform at least as well as your code (possibly doing the same thing
internally, if it's known to be safe) and likely even better if the
compiler is reasonably modern due special knowledge and treatment of
common functions/idioms.

Well, here are some benchmarks comparing the use of strcmp() to compare
short character strings (4 characters).

FreeBSD6.1/i386 using `gcc version 3.4.4 [FreeBSD] 20050518'
with "-pedantic -Wall -O5 -pipe -march=pentium4 -DNDEBUG -DNODEBUG
-fomit-frame-pointer":

./bench 100000000
str: used 1119486 microseconds
int: used 406449 microseconds

FreeBSD6.1/amd64 using the same compiler as above
with "-pedantic -Wall -O5 -pipe -march=opteron -DNDEBUG -DNODEBUG
-fomit-frame-pointer":

obj.amd64/bench 100000000
str: used 1403187 microseconds
int: used 392897 microseconds

AIX5.2/powerpc using IBM's cc with cc -O3 (-O4 would not link):

./aix-bench 100000000
str: used 3240000 microseconds
int: used 630000 microseconds

Solaris8/sparc using Sun's 6u2 compiler with `-v -fast' (fast is the "macro"
option turning on all possible optimizations including Sun's own libmil):

./sun4u-bench 100000000
str: used 7020000 microseconds
int: used 1300000 microseconds

the same using 64-bit binaries (-v -fast -xarch=v9b):

str: used 7920000 microseconds
int: used 1470000 microseconds

Solaris10/opteron using Sun's `cc: Sun C 5.7 2005/01/07' compiler with
`-fast -xarch=amd64':

./sunx86-bench 100000000
str: used 962088 microseconds
int: used 319509 microseconds

Of the above, the Sun's cc/libmil is definitely has the special "knowledge
and treatment of common functions/idioms" such as strcmp(), but even there
using strcmp() was 5 times slower...

It seems, that for the limited cases like this -- when the strings are of
the same length and fit nicely into an integer type -- treating them as such
is hugely beneficial. And, contrary to authoritative assertions posted in
this thread, compiler is NOT able to detect such cases.

I'm attaching (sigh) the simple-minded C-code to this posting -- please,
poke at it and/or reproduce my results... It even allows for CHAR_BIT to be
16 :-)

Thanks!

-mi

[Frederick Gotham]

Frederick Gotham posted:

If CHAR_BIT is 16, then all of the three "char" types must have 16
object representation bits.

Just to clarify:

It's possible to have a 16-Bit unsigned char and unsigned short, and yet have
an 8-bit signed char (which would contain 8 bits of padding).

--

Frederick Gotham

[Mikhail Teterin]

Frederick Gotham wrote:

It's possible to have a 16-Bit unsigned char and unsigned short, and yet
have an 8-bit signed char (which would contain 8 bits of padding).

But strcmp() expects "char *", so unsigned chars are not of concern for my
example, right?

-mi

[Keith Thompson]

Mikhail Teterin <us****@aldan.a lgebra.comwrite s:
[snip]

I'm attaching (sigh) the simple-minded C-code to this posting -- please,
poke at it and/or reproduce my results... It even allows for CHAR_BIT to be
16 :-)

Didn't we just go over this? Is there some reason you couldn't have
posted the C code as part of your article?

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Frederick Gotham]

Mikhail Teterin posted:

Frederick Gotham wrote:

>It's possible to have a 16-Bit unsigned char and unsigned short, and yet
have an 8-bit signed char (which would contain 8 bits of padding).

But strcmp() expects "char *", so unsigned chars are not of concern for my
example, right?

Sorry, I haven't looked at your example -- I just jumped into the thread when
I saw mention of the technicalities of integer types... like a bee to honey!
;)

--

Frederick Gotham

[Mikhail Teterin]

Keith Thompson wrote:

Didn't we just go over this? Is there some reason you couldn't have
posted the C code as part of your article?

We did. And I ended up convinced, that only inertia (and the desire to force
a newcomer to obey the rules of the club), are what makes this an issue in
the first place.

People with news-readers, that are not MIME-aware will just see these
textual attachments as part of the article.

MIME-aware news-readers will be able to handle them better this way...

Sorry, if it were one file, I would've inlined it, but three -- that's just
too much trouble.

-mi

[Keith Thompson]

Mikhail Teterin <us****@aldan.a lgebra.comwrite s:

Keith Thompson wrote:

>Didn't we just go over this? Is there some reason you couldn't have
posted the C code as part of your article?

We did. And I ended up convinced, that only inertia (and the desire to force
a newcomer to obey the rules of the club), are what makes this an issue in
the first place.

People with news-readers, that are not MIME-aware will just see these
textual attachments as part of the article.

MIME-aware news-readers will be able to handle them better this way...

Sorry, if it were one file, I would've inlined it, but three -- that's just
too much trouble.

Then you reached the wrong conclusion.

I, for one, will ignore any attachments posted to this newsgroup. I
will consider changing this policy only if there's a general consensus
among the regulars that text-only attachments are acceptable. (I'm
not claiming that this is a policy of the newsgroup; I speak only for
myself.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.