volatile (in comp.lang.c)

[David Collier-Brown]

In article <20345 at pyramid.pyramid.com> eric at pyrps5 (Eric Bergan) writes:
[in response to <488 at wsccs.UUCP>, from terry at wsccs.UUCP
| 	The flip side of the argument is "How far should we bend C for
| optimization purposes?" It would be great from an optimizer's viewpoint
| to be able to definitively know if a variable has no aliases. I suspect
| that this is too traumatic a change for the language, however, so
| we will have to rely on doing less optimization then might be available.
| (Have there been any studies of just how much performance improvements
| might be possible if an optimizer definitively knew what was and was
| not aliased?) 

 As a sidebar to the question, consider this fragment from
comp.arch, 
| Article 4111 of comp.arch:
| From: fnf at mcdsun.UUCP (Fred Fish)
| This is just the tip of the iceburg, there are lots of other optimizations
| that become obvious.  By examining the static and dynamic characteristics
| of the program, the data section objects can be sorted to get the most
| frequently used objects into low data memory.  The linker might also 
| decide that certain sections of the program reference portions of
| data memory more often than others, and insert the appropriate code to
| change the data mapping on the fly, rather than using a static mapping.

    It is interesting to note that there have not been, to date,
**any** other discussion of the necessity of "volatile" et all, only
of their desirability in a given language, taking their necessity as
**a given**.

    Are the two discussion groups disjoint? 

--dave (If you think that wasn't a nasty comment,
       sed <.signature 's/months/picoseconds/') c-b
-- 
 David Collier-Brown.                 {mnetor yunexus utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind) 
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.