Optimization, volatile (was Re: volatile)

[Greg Limes]

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.

Gee. I have used Sun equipment for the last three years, followed their
product line with avid interest for the last two, and worked there for
the last six months ... and have never heard of the Sun 400. Since
the hundreds digit tends to go up with power, and the top of the line
that I am aware of (engineer, not salesman) is the Sun-4/280, the
400 series must really be something.

End sarcasm.

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.

Porting from a Vax to a Sun-3 uncovers lots of problems, mostly dealing
with things like NULL pointer indirection; converting to a Sun-4
uncovers even more, mostly dealing with alignment problems -- where an
assumption is made about the lack of holes in structures, or specific
layout of data memory. Maybe even some assumption is made of layout of
function parameters in memory (on Sun4, they may not even BE there).

I try to code according to what appears to be the intent of K&R; after
all, that is how I learned the language: read K&R, write something,
compile it on an 11/50, make it work, think, read K&R, ...

>> Perhaps that sounds like nitpicking; I don't think it is.  To get back
>> to "volatile":  it provides a portable way to declare storage objects
>> that may change without notice, and thus is useful in writing portable
>> (not necessarily portable *everywhere*, but plenty portable for may uses)
>> programs that access device registers, use shared memory, signal handlers,
>> etc. (we've been over the whole list).
>
>yes, it's a nice toy on rare ocassion, but that's why #pragma was invented.

Have you ever written a device driver that had a top (mainline) half and
a bottom (interrupt) half? Probably not. For you, "volatile" is a toy.
For systems programming, and anybody who uses signal(), "volatile" is a
requirement. Making it a part of the language forces the syntax to be
the same across all systems that purport to support it; all others should
give errors.

>> 	we told them that we could have easily made our software 20-30%
>> 	faster, but couldn't be bothered for such an inconsequential gain.
>
>	A: Don't tell them and keep your job.

Your customers are smarter than they look. Remember, if only one of a
hundred picks up on this, and you have a thousand, someone will bring it
up in a user's group meeting. Or, worse yet, some competitor will be 10%
faster, causing a loss of that three billion dollar federal contract
that was *so* important. If I can get a gain of 1%, I go for it.

>> 	(3) "Let implementers of optimizing compilers come up with their
>> 	own pragmas that can turn off certain optimizations where they
>> 	will be destructive."  In other words, let each implementer
>> 	add "volatile" in her own way.  However, the semantics of
>> 	"volatile" are well-defined and broadly useful.  Making its
>> 	use non-portable is gratuitous.
>
>This is silly.  If ANSI thinks they can redefine C, why should #pragma be
>an effort in imagination?  Couldn't they say 'hey... use this'?

same difference, except that normally '#' stuff is handled by the
preprocessor, and 'volatile' as a keyword would be available as part of
the type in much the same way as 'unsigned'. Compilers with optimisers
that do not assume nonvolatile variables are free to ignore the keyword,
since it has no bearing on their output.
-- 
   Greg Limes [limes at sun.com]				frames to /dev/fb