Date:   Mon, 26 Jun 2017 13:07:09 -0700 (PDT)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     dlustig@...dia.com
CC:     patches@...ups.riscv.org
Subject:     Re: [PATCH 13/17] RISC-V: Add include subdirectory

On Wed, 07 Jun 2017 06:16:11 PDT (-0700), will.deacon@....com wrote:
> [sorry, jumping in here because it's the only mail I have relating to
>  patch 13]
>
> On Wed, Jun 07, 2017 at 02:58:50PM +0200, Peter Zijlstra wrote:
>> On Wed, Jun 07, 2017 at 02:36:27PM +0200, Peter Zijlstra wrote:
>> > Which (pending the sub confusion) will generate the entire set of:
>> >
>> >  atomic_add, atomic_add_return{_relaxed,_acquire,_release,} atomic_fetch_add{_relaxed,_acquire,_release,}
>> >  atomic_sub, atomic_sub_return{_relaxed,_acquire,_release,} atomic_fetch_sub{_relaxed,_acquire,_release,}
>> >
>> >  atomic_and, atomic_fetch_and{_relaxed,_acquire,_release,}
>> >  atomic_or,  atomic_fetch_or{_relaxed,_acquire,_release,}
>> >  atomic_xor, atomic_fetch_xor{_relaxed,_acquire,_release,}
>> >
>>
>> Another approach would be to override __atomic_op_{acquire,release} and
>> use things like:
>>
>> 	"FENCE r,rw" -- (load) ACQUIRE
>> 	"FENCE rw,w" -- (store) RELEASE
>>
>> And then you only need to provide _relaxed atomics.
>>
>> Also, and I didn't check for that, you need to provide:
>>
>> smp_load_acquire(), smp_store_release(), atomic_read_acquire(),
>> atomic_store_release().
>
> Is there an up-to-date specification for the RISC-V memory model? I looked
> at:
>
> https://github.com/riscv/riscv-isa-manual/releases/download/riscv-user-2.2/riscv-spec-v2.2.pdf

That's the most up to date spec.

> but it says:
>
> | 2.7 Memory Model
> | This section is out of date as the RISC-V memory model is
> | currently under revision to ensure it can efficiently support current
> | programming language memory models. The revised base mem- ory model will
> | contain further ordering constraints, including at least that loads to the
> | same address from the same hart cannot be reordered, and that syntactic data
> | dependencies between instructions are respected
>
> which, on the one hand is reassuring (because ignoring dependency ordering is
> plain broken), but on the other it doesn't go quite far enough in defining
> exactly what constitutes a "syntactic data dependency". The cumulativity of
> your fences also needs defining, because I think this was up in the air at some
> point and the document above doesn't seem to tackle it (it doesn't seem to
> describe what constitutes being a memory of the predecessor or successor sets)

Unfortunately I'm not really a formal memory model guy, so I probably know a
lot less about what a "syntactic data dependency" is than you do.  I believe
the plan (like for most of RISC-V) is to avoid doing anything weird, to support
existing software systems, and to allow for implementation flexibility where
possible.

> Could you shed some light on this please? We've started relying on RW control
> dependencies in semi-recent history, so it's important to get this nailed down.

This has been a sticking point for a while.  The result of lacking a proper
memory model has been that implementations have been extremely conservative and
as a result there aren't any issues in practice, but that itself is a bad
thing.

> Thanks,
>
> Will
>
> P.S. You should also totally get your architects to write a formal model ;)

The RISC-V organization has a working group defining a formal memory model.
Here's the original posting about the working group

  https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/Oxm_IvfYItY

To the best of my understanding we hope to have a formal memory model defined
by the end of the year.  I've added Daniel Lustig, the chair of the working
group, to the thread.  He knows a lot more about this than I do.

Powered by blists - more mailing lists