Alignment [was Re: Optimization, volatile]

[Tim Olson]

In article <51432 at sun.uucp> limes at sun.UUCP (Greg Limes) writes:
| In article <503 at wsccs.UUCP> terry at wsccs.UUCP (Every system needs one) writes:
| >This is the method one should use to determine if code is "bad"... but I
| >suggest you do not use a SUN 400* (matches all SUN 400 series) as your Sun,
| >as some of the assumptions it makes are _NOT_ K&R.
| 
| Yes, the Sun-4 systems have somewhat tighter restrictions than most
| previous archetectures. I would have been much happier if the hardware
| supported fixup of misaligned accesses, much like the 68020 supports
| arbitrarily aligned accesses. On the other hand, I do not remember K&R
| saying anything about arbitrary alignment of large storage cells. A
| quick look through the book, in fact, shows not only a lack of this
| assumption but also careful coding in the storage allocator (section
| 8.7, starting page 173 in my book) to assure that allocated blocks are
| properly aligned; it is assumed that, since the function returns a
| pointer to a character, the compiler will convert from (char *) to
| whatever type (foo *) the user wants.

In fact, K&R explicitly talk about alignment restrictions in many
places.  All you have to do is look in the index under (surprise)
"alignment restriction" to see the many discussions about it.

There is little doubt as to why DMR so carefully mentioned these
restrictions: the original C compiler was written for the PDP-11, which
had word accesses restricted to even-byte boundaries.  In fact, at least
3 of the four machines mentioned in K&R (PDP-11, IBM 360, and the Honeywell
6000) had such restrictions.

Perhaps Mr. Lambert would like to clarify what he means by "some of the
assumptions it makes are _NOT_ K&R"?

	-- Tim Olson
	Advanced Micro Devices
	(tim at amdcad.amd.com)