Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!oliveb!amdahl!amdcad!tim
From: tim@amdcad.AMD.COM (Tim Olson)
Newsgroups: comp.lang.c
Subject: Alignment [was Re: Optimization, volatile]
Message-ID: <21365@amdcad.AMD.COM>
Date: 30 Apr 88 21:06:09 GMT
References: <13074@brl-adm.ARPA> <2003@rtech.UUCP> <503@wsccs.UUCP> <51432@sun.uucp>
Reply-To: tim@amdcad.UUCP (Tim Olson)
Organization: Advanced Micro Devices
Lines: 33
Summary: Read K&R

In article <51432@sun.uucp> limes@sun.UUCP (Greg Limes) writes:
| In article <503@wsccs.UUCP> terry@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@amdcad.amd.com)