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

[Chris Dollin]

ar**********@gm ail.com wrote:

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.

That's up to the compiler, and it depends what you mean by "a 64 bit
machine".

If it is word aligned, what about the rest of the bytes.

What about the rest of what bytes?

What about the retrievel of the char c, will it be expensive.

That depends on the compiler. I wouldn't /expect/ it to be expensive.
`c` might well be stored in a register, for example [1].

Is it expensive w.r.t read or write.

That depends.

Have you a problem for which this would be an explanation?

(Ignoring your `...`s, the compiler could arrange that `main` above
is implemented with no local variables at all ...)

--
Chris "seeker" Dollin
"Reaching out for mirrors hidden in the web." - Renaissance, /Running Hard/

[Lew Pitcher]

ar**********@gm ail.com wrote:

Hi all,

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

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

Since character is 8 bit,

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.

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.

Storage and alignment are the concerns of the compiler and the
"execution platform". It /could/ be that this compiler does as you
suspect, and uses 8 bits out of 64 to store a char entity, leaving the
remaining bits unused and unusable.

Alternatively, the compiler /may/ reorganize your allocations (at any
one level) such that all the small entities are grouped together in
storage, permitting other char values to occupy the "slack" space from
your allocation of "char a;".

This is entirely up to the implementation of the compiler; AFAICR, the
C standard doesn't require any specific behaviour in this regard. If
the compiler's code organization and optimization are a problem for
you, you'll either have to switch compilers or change your code to live
more optimally within the restrictions that the compiler places on you.

Thanx and Regards,
Aruna

You're welcome
--
Lew Pitcher

[Walter Roberson]

In article <11************ **********@b28g 2000cwb.googleg roups.com>,
Lew Pitcher <lp******@sympa tico.cawrote:

>Alternativel y, the compiler /may/ reorganize your allocations (at any
one level) such that all the small entities are grouped together in
storage, permitting other char values to occupy the "slack" space from
your allocation of "char a;".

>This is entirely up to the implementation of the compiler; AFAICR, the
C standard doesn't require any specific behaviour in this regard.

I'm not sure what you mean by "at any one level".

Note that compilers are not permitted to reorder fields in a struct,
only to put padding between the fields. (I would tend to think
that fields of any one struct are all at the same "level", provided
they are not aggregate types.)
--
Programming is what happens while you're busy making other plans.

[Lew Pitcher]

Walter Roberson wrote:

In article <11************ **********@b28g 2000cwb.googleg roups.com>,
Lew Pitcher <lp******@sympa tico.cawrote:

Alternatively, the compiler /may/ reorganize your allocations (at any
one level) such that all the small entities are grouped together in
storage, permitting other char values to occupy the "slack" space from
your allocation of "char a;".

This is entirely up to the implementation of the compiler; AFAICR, the
C standard doesn't require any specific behaviour in this regard.

I'm not sure what you mean by "at any one level".

I wasn't too clear there, so let me elaborate

Assume the code fragment...

{
/* "level" A */
char aa; int ab, ac;
char ad;

{
/* "level" B */
char ae;

}
}

In the nesting level I've called "A", the compiler /may/ optimize the
allocations of aa, ab, ac, and ad so that aa and ad are adjacent in
"memory". For the OP's example of 8-bit char data items and 64bit
wordsizes, this could mean that 16bits of one 64bit word is occupied by
2 independant char data items, wasting only 48 bits of hidden padding
(assuming that the compiler word-aligns each allocation). The OPs
scenario would have each char data item (aa and ad) possible occupy 8
bits of unique 64bit words, leaving 112 bits (2 x 56) unused.

However, because variable ae is declared within a different "level" of
the code, I doubt that most compilers would "optimize" its allocation
to occupy another 8 bits within that 64bit allocation that aa and ad
potentially occupy.

That's what I meant by "at any one level"

Note that compilers are not permitted to reorder fields in a struct,
only to put padding between the fields. (I would tend to think
that fields of any one struct are all at the same "level", provided
they are not aggregate types.)

Up to this point, structure (and union) allocations haven't been part
of the discussion. Your point is taken; the compiler isn't permitted to
reorder fields within a structure, even in order to take advantage of
the potential space savings that such a reorganization might offer.

--
Lew Pitcher

[Mikhail Teterin]

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

-mi

[Walter Roberson]

In article <1953472.hIqUUy 82Sv@misha>,
Mikhail Teterin <us****@aldan.a lgebra.comwrote :

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

Note that int32_t is not certain to exist at all. There is an
int_least32_t that is certain to be at least 32 bits, and that will
exist on all C99 platforms.

sizeof int32_t will tell you how many "bytes" int32_t requires, and
by definition each char is exactly one byte long. However, it should
not be assumed that int32_t and char acCUR[sizeof int32_t] both
offer the same number of bits of "useable" storage, as the signed
int types are permitted to have internal non-value bits. When
you are trying to do type-punning via unions, you should use
unsigned char to be sure to be able to access all bits (including
the ones that the other fields might happen to treat as non-value bits.)
--
All is vanity. -- Ecclesiastes

[Lew Pitcher]

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;

Not portably, no.

int32_t isn't guaranteed to exist in every compliant compilation system

CHAR_BITS isn't guaranteed to be equal to 8 in every compliant
compilation system

char acCUR[4]; isn't guaranteed to contain 32 bits in every compliant
compilation system

[Flash Gordon]

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);
}

It definitely cannot. Apart from the fact that int could be only 16 bits
it could also have a trap representation, or two representations of the
same value (+0 and -0).

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

It could optimise it very easily using strcmp (inline the function and
then optimise it in place with the rest of the code). Potentially it
could be *more* efficient since it might compare fewer bytes.

If you think something like that is an optimisation worth considering
then you should not attempt *any* optimisation since at best you are
likely to have no effect or make it slower, but you are just as likely
to break it. Write code to be simple and understandable and let the
optimisation phase of the compiler do its job, it's probably a lot
better at it than you.
--
Flash Gordon
Still sigless on this computer.

[Eric Sosman]

Mikhail Teterin wrote On 08/14/06 13:50,:

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 trick will work on many machines, but you're right:
it works "by chance, not by design."

But is the loss worth weeping over? Consider: You've
saved a strcmp() of two short strings, but at what cost?
If your currency codes are "naturally" strings, you've now
got to bundle them up into xCUR unions; you must actually
copy the string characters into the acCUR members. This
uglifies your code -- and avoiding a strcmp() at the cost
of two calls to strcpy() doesn't seem like a step in the
right direction!

If you're making "a lot" of these comparisons, it might
make more sense to convert the strings to numeric codes at
the point when they're read in or whatever. You're probably
going to validate the strings by looking them up in a table
of "known" currency codes or some such, right? Having done
the lookup, it's pretty easy to get the table to provide an
easily-manipulated numeric code that can be used elsewhere in
the program; you'd just deal with strings "on the periphery."
That'd be cleaner, probably faster, and certainly more portable.

--
Er*********@sun .com