Memory model addendum to the user-level ISA spec v2.2

[Daniel Lustig]

Hi all,

 

Although the RISC-V memory consistency model is not yet complete, the RISC-V Foundation does not want to delay the ratification of the rest of the user-level ISA specification because of that.  Therefore, on behalf of the memory model task group and in collaboration with the Foundation, I’ve prepared a brief addendum to the current version of the user-level spec.  This addendum simply clarifies that the memory model is still being developed as of version 2.2, and it provides some advice on how current hardware and software can/should err on the side of caution until the memory model is nailed down more precisely.

 

The task group and I are working to get the memory model out as soon as we can.  In the meantime, feel free to ask questions here, and/or feel free to reach out to me or others on the task group directly.

 

Thanks,

Dan

---

This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

---

[Paolo Bonzini]

On 12/05/2017 15:30, Daniel Lustig wrote:
> Hi all,
>
>
>
> Although the RISC-V memory consistency model is not yet complete, the
> RISC-V Foundation does not want to delay the ratification of the rest of
> the user-level ISA specification because of that. Therefore, on behalf
> of the memory model task group and in collaboration with the Foundation,
> I’ve prepared a brief addendum to the current version of the user-level
> spec. This addendum simply clarifies that the memory model is still
> being developed as of version 2.2, and it provides some advice on how
> current hardware and software can/should err on the side of caution
> until the memory model is nailed down more precisely.

When you say "Assembly programmers should err on the side of caution and
assume that RISC-V may adopt a weakly ordered memory model", is that
"Alpha-like weak" or just "ARM-like weak"?

Paolo

[Andrew Waterman]

Definitely not Alpha-weak. We are aiming for organized chaos :-)

> --
> You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/639d61ae-cc01-ca68-2091-a32d969dc9b7%40gnu.org.

[Paolo Bonzini]

On 12/05/2017 17:53, Andrew Waterman wrote:
> Definitely not Alpha-weak. We are aiming for organized chaos :-)

Maybe you can add a clarification that "fence" should not be needed
between two loads, where the second is data-dependent on the first?

Thanks,

Paolo

[Daniel Lustig]

My personal opinion? More than likely we won't require a fence between two loads if the second is address-dependent on the first. Practically speaking, a lot of software (notably Linux) basically assumes that hardware always guarantees this to work, because no major architecture since Alpha has relaxed such orderings.

However, we don't yet have 100% consensus on how exactly to formalize this in the task group, and whether address, control, and data dependencies are all equivalent in strength, whether they apply equally well to read-read vs. read-write orderings, or even whether all of the above should even be enforced. So I don't think we're quite ready to commit to anything absolute yet.

So for now, I'd say the same thing I did for the other aspects of the addendum. Hardware should probably err on the side of caution and enforce all of the above dependency orderings. Software should probably err on the side of caution and emit fences anyway for now. More than likely, however, this advice will turn out to be overly conservative in one way or the other (or both), and can be relaxed later once things are more settled.

If anyone wants to weigh in on how terrible it would be for their software if dependency orderings weren't enforced, or how terrible it would be for their hardware if the above dependency orderings were all required, I'd be interested to hear the feedback.

Dan

-----------------------------------------------------------------------------------

This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.

-----------------------------------------------------------------------------------