Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pacbell!att!homxb!houxs!beyer
From: beyer@houxs.ATT.COM (J.BEYER)
Newsgroups: comp.arch
Subject: Re: Multi-Processor Serializability
Summary: Disabling of optimization does not help
Keywords: data ordering, coherence, shared memory multiprocessing
Message-ID: <1170@houxs.ATT.COM>
Date: 6 Feb 89 13:53:44 GMT
References: <3492@cloud9.Stratus.COM> <19635@lll-winken.LLNL.GOV> <3507@cloud9.Stratus.COM>
Organization: AT&T BL Holmdel NJ USA
Lines: 26

In article <3507@cloud9.Stratus.COM>, tomc@cloud9.Stratus.COM (Tom Clark) writes:
> > In ANSI C the tool to use to enforce reference order for reads and writes
> > is the keyword volatile, although I suppose that the purveyors of this keyword
> > did not have shared memory multiprocessors in mind when they inserted it into
> > the ANSI C definition.
> 
> Unfortunately volatile does not do it.  Volatile does indeed force a write
> to memory instead of holding an intermediate result in a register, but it
> says nothing about ordering of instructions.  Such a construct does not
> exist in most languages, except for the disabling of optimization.  Sigh.

The trick of disabling optimization to obtain a particular style of code
at the assembly-language level cannot be relied upon, because anything an
optimizer can do, a compiler can do as well. One need only imagine an ideal
compiler that produces perfect code without an optimizer. With such a compiler,
the concept of turning optimization does not exist. It seems to me that if
the higher level language in use does not support the semantics desired, you
must either rely on the characteristics of the compiler in use (and risk
portability), change to a higher level language that does support the desired
semantics, or write in a lower level language. But beware, some assemblers
have optimizers in them, too.

-- 
Jean-David Beyer
A.T.&T., Holmdel, New Jersey, 07733
houxs!beyer