Xref: utzoo comp.lang.c:9606 comp.arch:4463
Path: utzoo!utgpu!tmsoft!spectrix!yunexus!geac!daveb
From: daveb@geac.UUCP (David Collier-Brown)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: volatile (in comp.lang.c)
Summary: Sidebar on degree of optimization.
Message-ID: <2642@geac.UUCP>
Date: 24 Apr 88 19:25:59 GMT
References: <20345@pyramid.pyramid.com> <833@mcdsun.UUCP> <9916@tekecs.TEK.COM>
Reply-To: daveb@geac.UUCP (David Collier-Brown)
Organization: The Geac Cross-Reference Department
Lines: 38
Posted: Sun Apr 24 15:25:59 1988


In article <20345@pyramid.pyramid.com> eric@pyrps5 (Eric Bergan) writes:
[in response to <488@wsccs.UUCP>, from terry@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@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.