what does "strict alignment" mean?

[L. Chen]

The standard says that a char* or void* pointer has the least strict
alignment. But I do not know what is a strict alignment. What does that
mean?

[pete]

L. Chen wrote:

The standard says that a char* or void* pointer has the least strict
alignment. But I do not know what is a strict alignment.
What does that mean?

An object of type char, can exist at any byte address.
Other types, may only be able to exist at some addresses.

N869
3.1
[#1] alignment
requirement that objects of a particular type be located on
storage boundaries with addresses that are particular
multiples of a byte address

--
pete

[Tim Prince]

"pete" <pf*****@mindspring.com> wrote in message
news:41***********@mindspring.com...

L. Chen wrote:

The standard says that a char* or void* pointer has the least strict
alignment. But I do not know what is a strict alignment.
What does that mean?

An object of type char, can exist at any byte address.
Other types, may only be able to exist at some addresses.

Or, on the most common CPUs, performance may drop by 70% or more if they are
not so aligned.

[Malcolm]

"L. Chen" <ch*******@citiz.net> wrote

The standard says that a char* or void* pointer has the least strict
alignment. But I do not know what is a strict alignment. What does that
mean?

On some machines, it is not possible to read certain types except on word
boundaries. For instance, if integers are 32 bits

Load Accumulator 0x80000001 /* error, not a boundary */
Load Accumulator 0x80000004 /* ok. 32 bit boundary */

In order to produce efficient code, the C compiler will respect these
restrictions, for instance inserting padding bits in structures and
returning values from malloc() aligned on the strictest boundary.

One of the quirks of C is that "char" means "byte". By definition, a byte is
the smallest addressable unit of memory, so chars must have the least strict
alignment. Any address can contain a char.

[Tim Rentsch]

"Malcolm" <ma*****@55bank.freeserve.co.uk> writes:

One of the quirks of C is that "char" means "byte". By definition, a byte is
the smallest addressable unit of memory, so chars must have the least strict
alignment. Any address can contain a char.

What I think you mean is, a 'char' is the smallest unit of memory that
C guarantees you can address in C. But there's nothing preventing a
machine architecture that is addressable down to a single bit having a
C implementation where 'char' is 8 bits and only (bit) addresses that
were zero mod 8 were used in that C implementation. Right? This is
different from saying any [machine] address can contain a char.

[pete]

Tim Rentsch wrote:

"Malcolm" <ma*****@55bank.freeserve.co.uk> writes:

One of the quirks of C is that "char" means "byte".
By definition, a byte is the smallest addressable unit of memory,
so chars must have the least strict alignment.
Any address can contain a char.

What I think you mean is, a 'char' is the smallest unit of memory that
C guarantees you can address in C.

That's actually more like what a 'byte' is.

N869
3. Terms and definitions
3.4
[#1] byte
addressable unit of data storage large enough to hold any
member of the basic character set of the execution
environment
[#2] NOTE 1 It is possible to express the address of each
individual byte of an object uniquely.
[#3] NOTE 2 A byte is composed of a contiguous sequence of
bits, the number of which is implementation-defined. The
least significant bit is called the low-order bit; the most
significant bit is called the high-order bit.

--
pete

[Tim Rentsch]

pete <pf*****@mindspring.com> writes:

Tim Rentsch wrote:

"Malcolm" <ma*****@55bank.freeserve.co.uk> writes:

One of the quirks of C is that "char" means "byte".
By definition, a byte is the smallest addressable unit of memory,
so chars must have the least strict alignment.
Any address can contain a char.

What I think you mean is, a 'char' is the smallest unit of memory that
C guarantees you can address in C.

That's actually more like what a 'byte' is.

N869
3. Terms and definitions
3.4
[#1] byte
addressable unit of data storage large enough to hold any
member of the basic character set of the execution
environment
[#2] NOTE 1 It is possible to express the address of each
individual byte of an object uniquely.
[#3] NOTE 2 A byte is composed of a contiguous sequence of
bits, the number of which is implementation-defined. The
least significant bit is called the low-order bit; the most
significant bit is called the high-order bit.

Right. 'char' is the type, 'byte' is the name for the unit of memory.

My point was, what C thinks of as a byte is not necessarily the
smallest addressable unit in the machine architecture. Even a machine
that had 8-bit addressable units could have a C implementation where
'bytes' were 16 bits (and that might even make sense if the local
character set were something unicode-like).

[L. Chen]

"Tim Rentsch" <tx*@alumnus.caltech.edu> wrote in message
news:kf*************@alumnus.caltech.edu...

pete <pf*****@mindspring.com> writes:

Tim Rentsch wrote:

"Malcolm" <ma*****@55bank.freeserve.co.uk> writes:

> One of the quirks of C is that "char" means "byte".
> By definition, a byte is the smallest addressable unit of memory,
> so chars must have the least strict alignment.
> Any address can contain a char.

What I think you mean is, a 'char' is the smallest unit of memory that
C guarantees you can address in C.

That's actually more like what a 'byte' is.

N869
3. Terms and definitions
3.4
[#1] byte
addressable unit of data storage large enough to hold any
member of the basic character set of the execution
environment
[#2] NOTE 1 It is possible to express the address of each
individual byte of an object uniquely.
[#3] NOTE 2 A byte is composed of a contiguous sequence of
bits, the number of which is implementation-defined. The
least significant bit is called the low-order bit; the most
significant bit is called the high-order bit.

Right. 'char' is the type, 'byte' is the name for the unit of memory.

My point was, what C thinks of as a byte is not necessarily the
smallest addressable unit in the machine architecture. Even a machine
that had 8-bit addressable units could have a C implementation where
'bytes' were 16 bits (and that might even make sense if the local
character set were something unicode-like).

Thank you. I have one more question.
Then, if there are two pointers,

int* pn;
double* pd;

is the alignment requirement of pd stricter than that of pn ?

[Flash Gordon]

On Mon, 11 Oct 2004 10:52:07 +0800
"L. Chen" <ch*******@citiz.net> wrote:

<snip>

Thank you. I have one more question.
Then, if there are two pointers,

int* pn;
double* pd;

is the alignment requirement of pd stricter than that of pn ?

No. The standard does not impose any restrictions on what alignment the
implementation uses. It would be perfectly legal, although not very
sensible, to produce an implementation where int* pn had an allignment
requirement of 5 and double *pd had an alignment requirement of 3. Yes,
I did deliberately choose prime numbers!
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[pete]

L. Chen wrote:

Thank you. I have one more question.
Then, if there are two pointers,

int* pn;
double* pd;

is the alignment requirement of pd stricter than that of pn ?

Can't say.

Alignment requirements, go by type.
Alignment requirements are related to size, but two types
of the same size may have different alignment requirements.
While I would expect sizeof double to be larger than
sizeof int usually, it doesn't have to be.

--
pete

[Tim Prince]

"pete" <pf*****@mindspring.com> wrote in message
news:41**********@mindspring.com...

L. Chen wrote:

Thank you. I have one more question.
Then, if there are two pointers,

int* pn;
double* pd;

is the alignment requirement of pd stricter than that of pn ?

Can't say.

Alignment requirements, go by type.
Alignment requirements are related to size, but two types
of the same size may have different alignment requirements.
While I would expect sizeof double to be larger than
sizeof int usually, it doesn't have to be.

Perhaps more to the point, alignment requirement for double may be stricter
than for long long int. Certain compilers implement moves of double as
(normally slower) long long int moves, in order to avoid misalignment
penalty.

[Malcolm]

"Tim Rentsch" <tx*@alumnus.caltech.edu> wrote

My point was, what C thinks of as a byte is not necessarily the
smallest addressable unit in the machine architecture. Even a machine
that had 8-bit addressable units could have a C implementation where
'bytes' were 16 bits (and that might even make sense if the local
character set were something unicode-like).

"char" is a C word, whilst "byte" is a broader concept. K and R made a
mistake by calling "chars" (a variable holding a character) and "bytes" (the
smallest adressable unit of memory) the same thing. As it happens in English
it makes sense to store characters in eight bits, which is also a common
choice for the size of a byte, but this doesn't hold for other languages and
other architectures.
The fact that an "unsigned char" holds a byte is just something we have to
live with, and the problem is further confounded when C pointers differ from
architecture addresses, whether to support multi-byte chars or to implement
8-bit chars on machines where the underlying byte size is 32 bits. So we can
talk about C bytes and hardware bytes.