Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!sm.unisys.com!csun!polyslo!cquenel
From: cquenel@polyslo.CalPoly.EDU (88 more school days)
Newsgroups: comp.arch
Subject: Re: Multi-Processor Serializability
Keywords: data ordering, coherence, shared memory multiprocessing
Message-ID: <7650@polyslo.CalPoly.EDU>
Date: 2 Feb 89 18:39:08 GMT
References: <3492@cloud9.Stratus.COM> <19635@lll-winken.LLNL.GOV> <3507@cloud9.Stratus.COM>
Reply-To: cquenel@polyslo.CalPoly.EDU (88 more school days)
Organization: Blue Blaze Irregulars
Lines: 48

brooks@vette.llnl.gov (Eugene Brooks) 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.

tomc@cloud9.Stratus.COM (Tom Clark) writes:
>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.

Wait a minute.  What exactly is "ordering of instructions" ?
You talk about it as if there is one true "order" for instructions
generated by the compiler, and optimizations *change* that order.

The compiler GENERATES the order.  Probably no two compilers will
generate the SAME code sequence for a significantly large program.
So which one is right ?  *Neither* obviously, right ?  It depends.

So, what you're trying to say is this : I want the compiler
to generate code within certain constraints.  I want it to
generate code that is what I expect, so that I can second-guess
the code and do things with my code that are directly supported
by the language.

This is not a goal that I can frown on easily.

C's notable lack of support for multi-processor synchronization
makes it very tempting to try to wangle a way to *reliably* 
synchronize processes on different processors, however, this
is not a part of the language.

Unless you can define exactly WHAT your constraints are, you
can't expect a compiler implementor to generate his code
by any other rules than that of supporting the definition
of the language, and NOT "what the language has always done before."

The reason "it's always worked before" is a Marketing reason for
doing something, not a Software/Computer Engineering reason for
doing it.

--chris
-- 
@---@  -----------------------------------------------------------------  @---@
\. ./  |Chris Quenelle (The First Lab Rat) cquenel@polyslo.calpoly.edu |  \. ./
 \ /   |  YOU can do away with mode-less editors in YOUR life time!!!  |   \ / 
==o==  -----------------------------------------------------------------  ==o==