Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ztso psABI atomics specification #391

Merged
merged 1 commit into from
Aug 8, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
95 changes: 82 additions & 13 deletions riscv-atomic.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -6,10 +6,10 @@ endif::[]

== RISC-V atomics mappings

This specifies mappings of C and C\++ atomic operations to RISC-V
This specifies mappings of C and {Cpp} atomic operations to RISC-V
machine instructions. Other languages, for example Java, provide similar
facilities that should be implemented in a consistent manner, usually
by applying the mapping for the corresponding C++ primitive.
by applying the mapping for the corresponding {Cpp} primitive.

NOTE: Because different programming languages may be used within the same
process, these mappings must be compatible across programming languages. For
Expand All @@ -19,12 +19,12 @@ C.

NOTE: Though many mappings are possible, not all of them will interoperate
correctly. In particular, many mapping combinations will not
correctly enforce ordering  between a C++ `memory_order_seq_cst`
correctly enforce ordering  between a {Cpp} `memory_order_seq_cst`
store and a subsequent `memory_order_seq_cst` load.

NOTE: These mappings are very similar to those that originally appeared in the
appendix of the RISC-V "unprivileged" architecture specification as
"Mappings from C/C++ primitives to RISC-V Primitives", which we will
"Mappings from C/{Cpp} primitives to RISC-V Primitives", which we will
refer to by their 2019 historical label of "Table A.6". That mapping may
be used, _except_ that `atomic_store(memory_order_seq_cst)` must have an
an extra trailing fence for compatibility with the "Hypothetical mappings ..."
Expand Down Expand Up @@ -55,10 +55,10 @@ section deals with other read-modify-write operations that require
the `lr` and `sc` instructions.

[[tab:c11mappings]]
.Mappings from C/C++ primitives to RISC-V primitives
.Mappings from C/{Cpp} primitives to RISC-V primitives
[cols="<22,<18,<4",options="header",]
|===
|C/C++ Construct |RVWMO Mapping |Notes
|C/{Cpp} Construct |RVWMO Mapping |Notes

|Non-atomic load |`l{b\|h\|w\|d}` |

Expand Down Expand Up @@ -97,7 +97,7 @@ the `lr` and `sc` instructions.

[cols="<20,<20,<4",options="header",]
|===
|C/C++ Construct |RVWMO AMO Mapping |Notes
|C/{Cpp} Construct |RVWMO AMO Mapping |Notes

|`atomic_<op>(memory_order_relaxed)` |`amo<op>.{w\|d}` |4

Expand All @@ -113,7 +113,7 @@ the `lr` and `sc` instructions.

[cols="<16,<24,<4",options="header",]
|===
|C/C++ Construct |RVWMO LR/SC Mapping |Notes
|C/{Cpp} Construct |RVWMO LR/SC Mapping |Notes

|`atomic_<op>(memory_order_relaxed)` |`loop:lr.{w\|d}; <op>; sc.{w\|d}; bnez loop` |4

Expand All @@ -136,7 +136,7 @@ the `lr` and `sc` instructions.
=== Meaning of notes in table

1) Depends on a load instruction with an RCsc aquire annotation,
or a store instruction with an RCsc release annotation. These are curently
or a store instruction with an RCsc release annotation. These are currently
under discussion, but the specification has not yet been approved.

2) An RCpc load or store would also suffice, if it were to be introduced
Expand All @@ -148,11 +148,80 @@ mappings with code generated by a compiler using those older mappings.

4) Currently only directly possible for 32- and 64-bit operands.

=== Other conventions
== Ztso atomics mappings

It is expected that the RVWMO AMO Mappings will be used for atomic read-modify-write
operations that are directly supported by corresponding AMO instructions,
and that LR/SC mappings will be used for the remainder, currently
This specifies additional mappings of C and {Cpp} atomic operations to RISC-V
machine instructions.

For each construct, we provide a mapping that assumes only the A and Ztso
extension.

All mappings interoperate correctly with the RVWMO mappings, and with the
original "Table A.6" mappings.

We present the mappings as a table in 3 sections, as above.

[[tab:c11mappingsztso]]
.Mappings with Ztso extension from C/{Cpp} primitives to RISC-V primitives
[cols="<22,<18,<4",options="header",]
|===
|C/{Cpp} Construct |Ztso Mapping |Notes

|`atomic_load(memory_order_acquire)` |`l{b\|h\|w\|d}` | 5

|`atomic_load(memory_order_seq_cst)` |`fence rw,rw; l{b\|h\|w\|d}` | 5

|`atomic_store(memory_order_release)` |`s{b\|h\|w\|d}` | 5

|`atomic_store(memory_order_seq_cst)` |`s{b\|h\|w\|d}; fence rw, rw` | 5

|`atomic_thread_fence(memory_order_acquire)` |`nop` | 5

|`atomic_thread_fence(memory_order_release)` |`nop` | 5

|`atomic_thread_fence(memory_order_acq_rel)` |`nop` | 5
|===

[cols="<20,<20,<4",options="header",]
|===
|C/{Cpp} Construct |Ztso AMO Mapping |Notes

|`atomic_<op>(memory_order_acquire)` |`amo<op>.{w\|d}` |4, 5

|`atomic_<op>(memory_order_release)` |`amo<op>.{w\|d}` |4, 5

|`atomic_<op>(memory_order_acq_rel)` |`amo<op>.{w\|d}` |4, 5

|`atomic_<op>(memory_order_seq_cst)` |`amo<op>.{w\|d}` |4, 5

|===

[cols="<16,<24,<4",options="header",]
|===
|C/{Cpp} Construct |Ztso LR/SC Mapping |Notes

|`atomic_<op>(memory_order_acquire)`
|`loop:lr.{w\|d}; <op>; sc.{w\|d}; bnez loop` |4, 5

|`atomic_<op>(memory_order_release)`
|`loop:lr.{w\|d}; <op>; sc.{w\|d}; bnez loop` |4, 5

|`atomic_<op>(memory_order_acq_rel)`
|`loop:lr.{w\|d}; <op>; sc.{w\|d}; bnez loop` |4, 5

|===

=== Meaning of notes in table

4) Currently only directly possible for 32- and 64-bit operands.

5) Requires the Ztso extension.

== Other conventions

It is expected that the RVWMO and Ztso AMO Mappings will be used for atomic
read-modify-write operations that are directly supported by corresponding AMO
instructions, and that LR/SC mappings will be used for the remainder, currently
including compare-exchange operations. Compare-exchange LR/SC sequences
on the containing 32-bit word should be used for shorter operands. Thus,
a `fetch_add` operation on a 16-bit quantity would use a 32-bit LR/SC sequence.
Expand Down
4 changes: 2 additions & 2 deletions riscv-elf.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -266,8 +266,8 @@ raise an error.
RVE::: Linker should report errors if object files of different value
for RVE field.

TSO::: Linker should report errors if object files of different value
for TSO field.
TSO::: Input files can have different values for the TSO field; the linker
should set this field if any of the input objects have the TSO field set.

NOTE: The static linker may ignore the compatibility checks if all fields in the
`e_flags` are zero and all sections in the input file are non-executable
Expand Down
Loading