Re: Fortran volatile, was GNU C keyword volatile

"Nick Maclaren" <nmm1@cus.cam.ac.uk>
18 Oct 2002 23:03:44 -0400

          From comp.compilers

Related articles
GNU C keyword volatile, GNU compiler/optimizer and instruction re-or Arun@Winphoria.Com (Arun) (2002-09-19)
Re: GNU C keyword volatile, GNU compiler/optimizer and instruction nmm1@cus.cam.ac.uk (Nick Maclaren) (2002-09-20)
Re: GNU C keyword volatile, GNU compiler/optimizer and instruction re- mrs@kithrup.com (Mike Stump) (2002-09-29)
Re: GNU C keyword volatile, GNU compiler/optimizer and instruction r toon@moene.indiv.nluug.nl (Toon Moene) (2002-10-13)
Re: Fortran volatile, was GNU C keyword volatile nmm1@cus.cam.ac.uk (Nick Maclaren) (2002-10-18)
| List of all articles for this month |

From: "Nick Maclaren" <nmm1@cus.cam.ac.uk>
Newsgroups: comp.compilers
Date: 18 Oct 2002 23:03:44 -0400
Organization: University of Cambridge, England
References: 02-09-118 02-09-122 02-09-170 02-10-024
Keywords: C, Fortran
Posted-Date: 18 Oct 2002 23:03:44 EDT

Toon Moene <toon@moene.indiv.nluug.nl> wrote:
>
>> [I find that the main use of volatile is as a portable way to write
>> fundamentally unportable code like device drivers. -John]
>
>Please tell the Fortran Committee - see http://j3-fortran.org for the
>mailing lists. I've tried to argue this position in vain for about a
>year now, but - if nothing disatrous happens in the public review
>process - the VOLATILE attribute will be in Fortran 2000.


The Fortran 2000 specification strikes me as being not totally beyond
redemption; it has at least a single purpose and not two entirely
unrelated ones. However, it has one glaring flaw, and the following
is what I have sent off to various people in the UK:


5.1.2.16 VOLATILE attribute


This specification contains a serious omission: it does not address the
issue of whether the change can occur at the same time the object is
being accessed (i.e. genuinely asynchronously) or must occur between
accesses (i.e. atomically). As the use and implementation are both
COMPLETELY different between when these cases, there is ample scope for
the programmer to rely on one and the implementator to provide the
other.


Note that allowing asychronicity requires all three of the standard,
implementor and programmer to address the issue of objects that are
temporarily in 'impossible' states. C.2.3 implicitly assumes atomicity
- for, if not, why should all bits of the LOGICAL be updated
simultaneously, and why shouldn't they temporarily be invalid values?


[ A proposal to specify the atomic semantics. ]


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nmm1@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.