Optimization, volatile (was Re: volatile)

[Every system needs one]

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.
> 
> 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, please do.  A hypothetical Sun 400 would not be "really something" if
it were based on SPARC and the UNIX and C compilers for SPARC, as currently
formulated.

UNIX and C on SPARC are like the skin of a starving dog.  They are not
pleasent to look at or talk to; they will bite you if given the chance;
the underlying structure pokes through, making it hard to recognise the
entire assembly for what it is supposed to be.

> 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).

This is silly.  If you want, I will mail you an include file from software
that runs everywhere except SPARC. It is the machine.h, and has the names
of a hell of a lot of SUN competitors in it.  Any problems, therefore, by
weight of proven portabilty, would have to be the fault of the compiler
on the SPARC system.

> 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, ...

This would imply that you code by "11/50 standard", NOT 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.

In working for a company whose sole product is communications software,
I have probably written more device drivers than you.  I have never been so
unsure of my ability in assembly to assume that an optimising C compiler
could write better code than me.  Consequently, I code in assembly for speed
on my bottom half, knowing full well that a lot of hardware designers do
stupid things that require software tradeoffs which by necessity are ugly.
Coding a driver which can not truly hope to be hardware independant on the
"bottom" half in a portable language rather than the fastest available
language is kludgy.  Why make portable something which by it's nature can
never be portable?

> For systems programming, and anybody who uses signal(), "volatile" is a
> requirement.

anybody who uses signal() on a VMS system realises that you get an access
violation if you use it past a number of constructs necessary for I/O,
including, but not limited to, event flags, which are by definition "volitile".

For systems programming, a compiler that is not too stupid to realize when
certain memory areas are uncached for memory-mapped I/O purposes is a bad
compiler to use and ill-fitted to the hardware it is intended for.  In short,
it needs work.  I am suggesting that the work be done by the compiler writers.

> 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.

Gee, is that so I can use my VME bus drivers with my  Q bus?  Get real.

> >> 	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.

Remember, also, the assumption was that the customers did not know.  Also,
remember that the context from which you removed this was a sarcastic
reply to the fallacious idea that it was impossible to tell when something
was volitile by having the compiler _look_ the right way.  Simply coding
into the compiler the rules which you yourself use to determine when to code
something volitile whould eliminate the need in the majority of cases.

> >> 	(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.

Except that I don't have to live with it if it's in the preprocessor.  If it's
"same difference", what's the bitch with putting it there?


Please do not take this as a condemnation of all Sun products.  Sun has a
long history of excellent hardware and software prior to SPARC, and I am
sure they will come to their senses and either rewrite the UNIX and/or the
compiler or simply can it.  Portability of new applications is not the
question; porting of older applications is.  It is more important that the
majority of code run rather than the minority of code running faster.  I am
just trying to do my part to hurry this day.


| 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!' |