Alignment [was Re: Optimization, volatile]

[Every system needs one]

[ ut-oh.  They got me started on SPARC again...]

In article <503 at wsccs.UUCP> I write:
| >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.

In article <51432 at sun.uucp> limes at sun.UUCP (Greg Limes) replies (with no
tendency toward jingoism, considering his address?):
| 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 article <21365 at amdcad.AMD.COM>, tim at amdcad.AMD.COM (Tim Olson) makes
the assumtion that Greg is referring to some comments I made about how
"structure alignment is discussed in K&R", and goes on to lambast me:
> 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"?

Yes, Perhaps he might.  Can you say VARARGS?

1) I can't write a printf() replacement that is always happy.
2) I can't write a main() which calls my_main() (I have this sort of fetish
   when it comes to being able to debug my programs) that is always happy.
3) '/* VARARGS */' is a comment used by lint, NOT a compiler directive.

Can you say alignment?

1) struct astruct *foo; foo = (astruct *)malloc( sizeof(struct astruct));
   doesn't always work when you have a large data segment or have to
   fix the stack size.
2) A struct should not have "random" holes, depending on word alignment,
   where it it necessary to have the first item in your struct be "word-sized"
   for sizeof( struct astruct) to return the actual length.  Otherwise, when
   you malloc(), the resultant pointer could be byte aligned, then have a
   "random" number of empty bytes if the structure were set up such that
   struct astruct { char fee; int fie;};.  This would cause such common code
   as a write() for sizeof(struct astruct) of a malloc'ed structure's contents
   to not work reliably.
3) int is the basic type in C.  Sign extension from something like the following
   int i;  char fum;
   i = (unsigned char)fum;
   can fail to properly handle the high(sign) bit, in that an extension can
   still occurr when it souldn't.
4) Due to cacheing and the methodlogy used to impliment pipes, pipes like
   to word-align their data.  An ioctl( TIOCQCNT); (or whatever the equivalent
   is on the bloody machine) can therefore return an incorrect count of the
   characters in a pipe if numchars%(sizeof(int)/sizeof(char))!=0.  This can
   be remedied using a flush, but that flush was NOT previously necessary.
5) A popen() of the line printer spooler wherein the program writes to the
   pipe to produce a report that doesn't stomp on other output (by snarfing
   /dev/lpr or whatever) and want's to avoid tmp files and child processes
   must also, by the same token, flush it's pipe before exiting, as a close
   will hang the process.

While these things are mostly OS bugs shown up by the architecture being too
close to the surface, or C compiler bugs generated by an effort to make the
architecture look fast.  It didn't fool me.

In the subset of C I program in, my programs will run on the SPARC.  But it
is a subset; SPARC should have been implemented such that the optimization
and "speed-up" decisions made in the compiler did not effect portability of
any code.  SPARC is not inherently bad; the aparrently marketing necessity
of implementing the C compiler such that it does stupid things IS bad.  If
it takes longer to compile a program, that is the price of SPARC.

Rather than grilling me with statements that say the combination of hardware
software which make up the C compiler environment ARE strictly K&R standard,
realise that:

	1) I do not cede that point; I don't think you can throw all of
	   the above out.  Maybe some, if I have typoed in an example or
	   if you are just trying to pick a fight, but not all.
	2) If I were to do so, it is still a bad decision for a company
	   to make it difficult to port to their machines.  I evidence
	   the HP-3000 and all those wonderful graphics programs for
	   the blockmode controllers on large IBM systems (I don't think
	   there are any)
	3) I know of at least 7 software companies who will not release
	   their products on the Sun systems SPARC as they have presently
	   implemented UNIX and C.  5 of them are winners of the "best of
	   UNIX software" awards, presented by UNIX WORLD magazine.

When you can say "yes" when your customer asks "does it run this", you can't
sell it.

When the customer calls their software vendor prior to buying a new machine
to make sure he can run "his programs", and there isn't a version for the
new machine, he won't buy the machine.

"The Bottom Line" IS the bottom line.


| Terry Lambert           UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry |
| @ Century Software        OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |
| 'Admit it!  You're just harrasing me because of the quote in my signature!' |