From mboxrd@z Thu Jan 1 00:00:00 1970 From: toddpw@ugcs.caltech.edu (Todd P. Whitesel) To: mlist-egcs@nntp-server.caltech.edu Subject: Re: Incrementing volatiles? Date: Mon, 13 Jul 1998 00:06:00 -0000 Message-id: <6ocb7d$kbu@gap.cco.caltech.edu> References: X-SW-Source: 1998-07/msg00436.html Horst von Brand writes: >Sorry if I'm being dense... I just don't see any difference here: both are >fetched, incremented and written back. And if it's "implementation defined", >gcc is free to optimize this, isn't it? Sort of. While the language standard that says "implementation defined" does allow gcc to optimize it, many of the actual _users_ of gcc have a very clear idea as to what 'volatile' means, and gcc needs to accomodate them. The unwritten but de facto definition of volatile is that the activity on all objects declared volatile (number of accesses, whether they are read or write, the size of them, and the order of them) must remain the same independent of the optimization level. On "enough" systems this satisfies the condition that all I/O peripherals and shared memory devices see the same events in the same time order for each basic block in the program. Thus, most people's ideas of how to write device drivers and multi-threaded code continue to work even when heavy optimization is enabled. It sounds to me that gcc is using an extremely conservative (but also very safe, since handling of volatile is in principle very difficult to test!!) implementation of volatile. I would strongly recommend leaving it the way it is until a truly serious effort can be made to improve optimization of volatile objects -- including exhaustive simulation of the target processors to ensure that the relevant visible 'bus cycles' do not change when optimization is enabled. Since the sim/ directory would be the first place tapped for simulator technology, more targets implemented in there would be A Good Thing. Todd Whitesel toddpw @ ugcs.caltech.edu