Implementation of memory model

[Boehm, Hans]

I agree completely.  My point was really that the support of various
compiler implementers is far more convincing than a single existence
proof, which might have happened not to perform any dubious optimizations
to start with.  In that sense, I think this is different from a language
extension proposal, where the existence proof is critical.

Several (most?) of us have experience building compilers, so I
don't think we're in bad shape as far as the initial work is concerned.

Hans

> -----Original Message-----
> From: Andrei Alexandrescu [mailto:andrei at metalanguage.com]
> Sent: Thursday, September 23, 2004 2:17 PM
> To: Boehm, Hans
> Cc: Ben Hutchings; Kevlin Henney; Bill Pugh; Douglas C. Schmidt; Doug
> Lea
> Subject: Re[2]: Implementation of memory model
> 
> 
> Hans,
> 
> A   memory  model  that  works  only  for  unoptimizing  builds  would
> definitely be a letdown.
> 
> A  compiler  writer  would help by pointing out possible optimizations
> that our abstraction either disables, or is too ambiguous to enable. I
> could  fill  or  at  least  help  filling that role; I've been writing
> optimizers for a couple of years.
> 
> Andrei
> 
> Thursday, September 23, 2004, 1:47:29 PM, you wrote:
> 
> > Andrei, Ben -
> 
> > I'm not sure exactly what kind of implementation effort 
> we're talking
> > about here.
> 
> > I think we're likely to come up with a memory model
> > that would be satisfied by the current g++ -O0 on X86, IA64,
> > SPARC TSO or PA (and probably many other compilers and platforms
> > at minimal optimization).  Thus I expect that for this part
> > we'll have an existence proof without doing any real work.
> > We'll of course still need the opinions of compiler
> > implementers as to the effect on current and future optimizations,
> > though I think several of us have some reasonable understanding
> > of those issues.  It would be good to have an optimizer that
> > obeys whatever rules we propose, but I'm not sure it's either
> > essential or terribly convincing, since I think any effect is
> > likely to be very compiler- and architecture-dependent.
> 
> > We will of course need an implementation of the library components.
> > But I'd be unhappy of that took a lot of new work.  I would guess
> > that, for compilers that currently provide access to atomic 
> operations
> > and barriers via intrinsics or inline assembly, it should 
> be possible
> > to make a first pass at this without touching the compiler.
> 
> > Hans 
> 
> >> -----Original Message-----
> >> From: Andrei Alexandrescu [mailto:andrei at metalanguage.com]
> >> Sent: Friday, September 17, 2004 1:36 AM
> >> To: Ben Hutchings
> >> Cc: Hans Boehm; Kevlin Henney; Bill Pugh; Douglas C. 
> Schmidt; Doug Lea
> >> Subject: Re: Implementation of memory model
> >> 
> >> 
> >> My hope is to convince Howard Hinnant to join us by using beer as
> >> bribe.
> >> 
> >> Andrei
> >> 
> >> Thursday, September 16, 2004, 5:23:04 PM, you wrote:
> >> 
> >> > I expect that it will be necessary to get some 
> >> implementation experience
> >> > with any proposed memory model in order to produce a 
> >> practical proposal
> >> > that implementers will support and will adhere to if and 
> >> when it becomes
> >> > part of the next standard (or even before then).  It will 
> >> surely benefit
> >> > from Bill and Doug's experience with defining the Java 
> >> memory model, but
> >> > there are issues with C++ that don't arise in Java.
> >> 
> >> > Now correct me if I'm wrong, but I don't think any of you 
> >> are involved
> >> > in implementation of C++ compilers.  So I think we should 
> >> try to get at
> >> > least one implementer involved in this.  Perhaps you 
> >> already planned to
> >> > do this at the Redmond meeting, Andrei?  Alternately it may 
> >> be possible
> >> > for one or more of us to try out changes to GCC or EDG's 
> >> C++ compiler,
> >> > though I suspect that's much easier said than done.
> >> 
> >> > Ben.
> >> 
>