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

[Keith Thompson]

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

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?

I haven't looked at your example lately, but strcmp() in effect works
with unsigned chars. Its declaration makes it look like it deals
with plain chars:

int strcmp(const char *s1, const char *s2);

but:

The sign of a nonzero value returned by the comparison functions
memcmp, strcmp, and strncmp is determined by the sign of the
difference between the values of the first pair of characters
(both interpreted as unsigned char) that differ in the objects
being compared.

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

[Mikhail Teterin]

Keith Thompson wrote:

I, for one, will ignore any attachments posted to this newsgroup.

I have not spent much time on this group, but, so far, I have not seen
anything that would make me truly saddened by your decision...

I will consider changing this policy only if there's a general consensus
among the regulars that text-only attachments are acceptable.

You are confirming my impression, that the actual merits of text-only
attachments are secondary (or even fully irrelevant) to your decision, with
the annoyance over my violating the unwritten and unofficial "rules of the
club" being the primary...

-mi

[Ian Collins]

Keith Thompson wrote:

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

In this case, I found the attachments handy, just a quick 'save all' in
Mozilla, rather than several copy and pastes.

For a single file, inline is probably best, but for several attachments
can help

--
Ian Collins.

[Al Balmer]

On Wed, 16 Aug 2006 20:03:57 -0400, Mikhail Teterin
<us****@aldan.a lgebra.comwrote :

>Keith Thompson wrote:

>I, for one, will ignore any attachments posted to this newsgroup.

I have not spent much time on this group, but, so far, I have not seen
anything that would make me truly saddened by your decision...

>I will consider changing this policy only if there's a general consensus
among the regulars that text-only attachments are acceptable.

You are confirming my impression, that the actual merits of text-only
attachments are secondary (or even fully irrelevant) to your decision, with
the annoyance over my violating the unwritten and unofficial "rules of the
club" being the primary...

Actually, I think the annoyance comes from your continuing to argue
about it after being informed about the "unwritten and unofficial
rules of the club". The "club", incidentally, includes very many
usenet groups. As it says in http://www.netmeister.org/news/usenet/
after mentioning that many users still use dialup:

"Let this be just one reason why you should never ever post an
attachment into a newsgroup that does not specifically state in its
Charta that it is desired. Usually, attachments are only appropriate
in *binaries*-newsgroups."

--
Al Balmer
Sun City, AZ

[websnarf]

Mikhail Teterin wrote:

Lew Pitcher wrote:

Actually, a character isn't 8 bit. I'm simplifying a bit, but a
character is guaranteed to be /at least/ 8 bits wide, and is permitted
to be as wide as necessary. For all we (or you) know, a char might be
64bits wide on your platform.

So, comparing, say, 4-char arrays (like currency codes) can NOT be done in
the following way?

typedef union {
char acCUR[4];
int32_t iCUR;
} xCUR;

int
CurEqual(xCUR *c1, xCUR *c2)
{
if (c1->iCUR == c2->iCUR)
printf("Same currency %s\n", c1->acCUR);
else
printf("%s and %s are different\n",
c1->acCUR, c2->acCUR);
}

Having to call a strcmp() in such cases seems like a bad waste to me, but I
don't see, how the compiler could possibly optimize such a code without the
trick above...

The compiler cannot do that optimization because its not correct.
strcmp() stops executing its inner loop once it reads a '\0'. I.e.,
its possible for the strcmp()'s to be equal where the int32_t's are not
equal. Also the compiler is allowed to align struct entries as they
like. So on a 64 bit big endian system, the int32_t might not
intersect with any of the 4 acCur[] characters.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Eric Sosman]

Mikhail Teterin wrote:

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

Good. Splendid. But: HOW MUCH faster?

Elsethread you have posted an attempt to quantify HOW MUCH,
and your results suggest that the particular "cool" trick you
favor will save ...

0.0000000071303 7 seconds per comparison.

(Frankly, I doubt that the measurement accuracy justifies the
number of "significan t" digits you've reported, but let that
pass: 0.0000000071303 7 seconds it is. Congratulations on your
savings; don't spend it all in one place.)

To save one second, you need to make 140245176+ comparisons.

To save the -- what? hour? let's be generous and say thirty
minutes -- to recoup the thirty minutes you have already spent
on this folly, JUST TO BREAK EVEN, you need to make 252441317912
comparisons. That number is almost fifty-nine times larger than
the largest value of an `unsigned int' on many implementations ;
you will have trouble even *counting* the number of comparisons
you must make before you break even.

Thesis: A program that makes 252441317912 comparisons doesn't
need to make those comparisons faster; it needs a way to avoid
all those stupid comparisons!

Mikhail, I can see your error and understand it and sympathize
with it, because in my mis-spent youth I made the same mistake. I
claim no superiority; it's quite possible (maybe even likely) that
my sins were greater than yours are, that I exercised even worse
judgement than you are exercising now. As a sort of reformed drunk
I address the AA meeting: You are on the broad highway to Hell. You
have become besotted (as I in my time was besotted) with "clever"
tricks and "subtle" devices, and (like me) you have not stopped to
count the cost. Consider: You are giving up portability, you are
giving up clarity, you are diminishing maintainability -- and for
what? For a gain of less than one second.

Bad trade, Mikail. Very bad trade. Chortle over the cleverness
of whatever gadget takes your fancy -- but don't use it. Just don't.
You will come to regret your ingenuity -- trust me on this; I deployed
above-average ingenuity, and in the long run got into above-average
trouble. Stop, sinner, while there is yet time.

Enuf. I'm outta here.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Eric Sosman]

we******@gmail. com wrote:

Mikhail Teterin wrote:

>>
So, comparing, say, 4-char arrays (like currency codes) can NOT be done in
the following way?

typedef union {
char acCUR[4];
int32_t iCUR;
} xCUR;
[...]

Having to call a strcmp() in such cases seems like a bad waste to me, but I
don't see, how the compiler could possibly optimize such a code without the
trick above...

The compiler cannot do that optimization because its not correct.
strcmp() stops executing its inner loop once it reads a '\0'. I.e.,
its possible for the strcmp()'s to be equal where the int32_t's are not
equal. Also the compiler is allowed to align struct entries as they
like. So on a 64 bit big endian system, the int32_t might not
intersect with any of the 4 acCur[] characters.

Agree with the first part but not with the second. Look
again: it's not a struct, but a union.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Frederick Gotham]

Eric Sosman posted:

0.0000000071303 7 seconds per comparison.

7 million femtoseconds! Wow! ; )

--

Frederick Gotham

[Keith Thompson]

Keith Thompson <ks***@mib.orgw rites:
[...]

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

I believe I was too hasty in making this statement. I've started a
new thread to discuss this issue.

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

[websnarf]

Mikhail Teterin wrote:

Keith Thompson wrote:

For example, you could have c1->acCUR equal to
{ 'X', 'Y', '\0', 'A' }
and c2->acCUR equal to
{ 'X', 'Y', '\0', 'B' }
Not all the corresponding array elements are equal, but strcmp() will
ignore the 'A' and 'B' characters.

I know. Currencies, however, are all 3-character strings (plus the
terminating '\0'). Thus they are perfectly suited to be treated as int32_t,
when convenient.

If that is true, then in fact this is a useful performance boost, but
its platform specific. Personally, I would just capture it like this:
*((int32_t *) &currency) rather than bothering with the union.

That it is not 100% portable is already rammed into me by the friendly folks
on this board. I'd like to know an example of the actual hardware/compiler
combo, where it would not work, though...

I am pretty sure there are real 64 bit systems (though likely they are
marginal) that will fail to do your trick correctly. Not AMD64, but
some old Crays or Sparc64s might in fact fail (they need to be big
Endian, and align struct/union entries to 64 bits). And obviously
those silly DSPs that don't support int32_t's would just fail to
compile your code.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/