Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!oliveb!pyramid!markhall
From: markhall@pyramid.pyramid.com (Mark Hall)
Newsgroups: comp.arch
Subject: Re: Multi-Processor Serializability
Keywords: data ordering, coherence, shared memory multiprocessing
Message-ID: <58218@pyramid.pyramid.com>
Date: 7 Feb 89 17:44:02 GMT
References: <3492@cloud9.Stratus.COM> <19635@lll-winken.LLNL.GOV> <3507@cloud9.Stratus.COM> <1170@houxs.ATT.COM>
Reply-To: markhall@pyramid.UUCP (Mark Hall)
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 25

In article <3507...>, 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, 
> 
> 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.  

I must be wrong about this (cuz no one else has posted it yet)
but are you SURE ANSI volatile ``says nothing about the ordering
of instructions''?  Well, what does the part about ``the value
of the volatile object shall agree with that prescribed by the
abstract machine at all sequence points''?  Dang, I thought it
meant that you couldn't move computations involving volatile
object across sequence points, which to me means you have
constraints on ordering.  As for operator application order, for
the expression  a <op1> b <op2> c, the evaluation must proceed
`as if' op1 were applied first, and then op2, etc.

I don't get it (I'm sure someone will set me straight, though).

(I love getting into these discussions a month late).

-Mark Hall (smart mailer): markhall@pyramid.pyramid.com
	   (uucp paths): {ames|decwrl|sun|seismo}!pyramid!markhall