Optimization, volatile (was Re: volatile)

[der Mouse]

In article <527 at wsccs.UUCP>, terry at wsccs.UUCP (Every system needs one) writes:
> In article <51432 at sun.uucp>, limes at sun.uucp (Greg Limes) writes:
>> Porting from a Vax to a Sun-3 uncovers lots of problems, [...];
>> 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 [...].
> This is silly.  If you want, I will mail you an include file from
> software that runs everywhere except SPARC.

Well, I guess the code needs cleaning up a little then.

> Any problems, [...] by weight of proven portabilty, would have to be
> the fault of the compiler on the SPARC system.

What's special about SPARC?  Your code initially ran on some machines
X, Y, and Z; then you ported it to machine W and it needed some work
(it wasn't portable enough).  Now you go to port it to the SPARC and it
needs more work, and suddenly it's the machine rather than your code at
fault?  C doesn't guarantee nearly as much as most people seem to think.

>>>> [why volatile is good]
>>> 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?  [If not], "volatile" is a toy.
> [...] 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.

But don't assume that it can't, either.  Optimizer technology is very
good, and getting better all the time.

> Consequently, I code in assembly for speed on my bottom half, [...].
> 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?

So that it's readable and maintainable.  And portability means more
than "compiles without change elsewhere".  If I have a device driver
written for a Sun that implements some messy protocol over a parallel
port, and need a driver for a VAX that implements the same messy
protocol over a parallel port there, I'd much rather have to port a C
driver than an assembly driver.

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

Then I would say the VMS implementation is broken.

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

Yes.  See above.

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

The compiler doesn't have as much information as you.  In the case of
most programmers, it is substantially less intelligent as well.

[someone suggests that volatile be a #pragma]
>> same difference, except that normally '#' stuff is handled by the
>> preprocessor, and 'volatile' as a keyword would be [...]
> 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?

If the optimizer is such that it needs the hint provided by "volatile"
(pragma or keyword, whatever), then you can (a) turn off the optimizer,
or at least that part of it (which means most of it) or (b) never deal
with (write or modify) code that needs volatile.  Or get another
compiler, or take up knitting....  Your competitors will happily get a
compiler with a serious optimizer, use volatile, and blow by you
(unless you chose option (b)).

The only difference between using a #pragma for volatile and using a
keyword is one of uniformity.  People who aren't concerned with issues
of volatility can ignore it equally well in either form.  People who do
care would like to be able to use the same means everywhere.  (Can you
imagine the chaos that would result if each compiler had invented its
own syntax for declarations, say?)

					der Mouse

			uucp: mouse at mcgill-vision.uucp
			arpa: mouse at larry.mcrcim.mcgill.edu