Skip to content

Commit 64fbc24

Browse files
author
Derek Hower
committed
Change extension schema
1 parent 923badf commit 64fbc24

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

67 files changed

+4837
-4726
lines changed

‎arch/ext/A.yaml‎

Lines changed: 114 additions & 112 deletions
Original file line numberDiff line numberDiff line change
@@ -1,123 +1,125 @@
11
# yaml-language-server: $schema=../../schemas/ext_schema.json
22

3-
A:
4-
type: unprivileged
5-
long_name: Atomic instructions
6-
company:
7-
name: RISC-V International
8-
url: https://riscv.org
9-
versions:
10-
- version: "2.1.0"
11-
state: ratified
12-
ratification_date: 2019-12
13-
contributors:
14-
- name: Unknown
15-
email: [email protected]
16-
company: Unknown
17-
implies:
18-
- [Zaamo, "1.0.0"]
19-
- [Zalrsc, "1.0.0"]
20-
description: |
3+
$schema: "ext_schema.json#"
4+
kind: extension
5+
name: A
6+
type: unprivileged
7+
long_name: Atomic instructions
8+
company:
9+
name: RISC-V International
10+
url: https://riscv.org
11+
versions:
12+
- version: "2.1.0"
13+
state: ratified
14+
ratification_date: 2019-12
15+
contributors:
16+
- name: Unknown
17+
email: [email protected]
18+
company: Unknown
19+
implies:
20+
- [Zaamo, "1.0.0"]
21+
- [Zalrsc, "1.0.0"]
22+
description: |
2123
22-
The atomic-instruction extension, named `A`, contains
23-
instructions that atomically read-modify-write memory to support
24-
synchronization between multiple RISC-V harts running in the same memory
25-
space. The two forms of atomic instruction provided are
26-
load-reserved/store-conditional instructions and atomic fetch-and-op
27-
memory instructions. Both types of atomic instruction support various
28-
memory consistency orderings including unordered, acquire, release, and
29-
sequentially consistent semantics. These instructions allow RISC-V to
30-
support the RCsc memory consistency model. cite:[Gharachorloo90memoryconsistency]
24+
The atomic-instruction extension, named `A`, contains
25+
instructions that atomically read-modify-write memory to support
26+
synchronization between multiple RISC-V harts running in the same memory
27+
space. The two forms of atomic instruction provided are
28+
load-reserved/store-conditional instructions and atomic fetch-and-op
29+
memory instructions. Both types of atomic instruction support various
30+
memory consistency orderings including unordered, acquire, release, and
31+
sequentially consistent semantics. These instructions allow RISC-V to
32+
support the RCsc memory consistency model. cite:[Gharachorloo90memoryconsistency]
3133
32-
[NOTE]
33-
====
34-
After much debate, the language community and architecture community
35-
appear to have finally settled on release consistency as the standard
36-
memory consistency model and so the RISC-V atomic support is built
37-
around this model.
38-
====
34+
[NOTE]
35+
====
36+
After much debate, the language community and architecture community
37+
appear to have finally settled on release consistency as the standard
38+
memory consistency model and so the RISC-V atomic support is built
39+
around this model.
40+
====
3941
40-
The `A` extension comprises instructions provided by the `Zaamo` and `Zalrsc`
41-
extensions.
42+
The `A` extension comprises instructions provided by the `Zaamo` and `Zalrsc`
43+
extensions.
4244
43-
= Specifying Ordering of Atomic Instructions
45+
= Specifying Ordering of Atomic Instructions
4446
45-
The base RISC-V ISA has a relaxed memory model, with the `FENCE`
46-
instruction used to impose additional ordering constraints. The address
47-
space is divided by the execution environment into memory and I/O
48-
domains, and the `FENCE` instruction provides options to order accesses to
49-
one or both of these two address domains.
47+
The base RISC-V ISA has a relaxed memory model, with the `FENCE`
48+
instruction used to impose additional ordering constraints. The address
49+
space is divided by the execution environment into memory and I/O
50+
domains, and the `FENCE` instruction provides options to order accesses to
51+
one or both of these two address domains.
5052
51-
To provide more efficient support for release consistency cite:[Gharachorloo90memoryconsistency], each atomic
52-
instruction has two bits, _aq_ and _rl_, used to specify additional
53-
memory ordering constraints as viewed by other RISC-V harts. The bits
54-
order accesses to one of the two address domains, memory or I/O,
55-
depending on which address domain the atomic instruction is accessing.
56-
No ordering constraint is implied to accesses to the other domain, and a
57-
FENCE instruction should be used to order across both domains.
53+
To provide more efficient support for release consistency cite:[Gharachorloo90memoryconsistency], each atomic
54+
instruction has two bits, _aq_ and _rl_, used to specify additional
55+
memory ordering constraints as viewed by other RISC-V harts. The bits
56+
order accesses to one of the two address domains, memory or I/O,
57+
depending on which address domain the atomic instruction is accessing.
58+
No ordering constraint is implied to accesses to the other domain, and a
59+
FENCE instruction should be used to order across both domains.
5860
59-
If both bits are clear, no additional ordering constraints are imposed
60-
on the atomic memory operation. If only the _aq_ bit is set, the atomic
61-
memory operation is treated as an _acquire_ access, i.e., no following
62-
memory operations on this RISC-V hart can be observed to take place
63-
before the acquire memory operation. If only the _rl_ bit is set, the
64-
atomic memory operation is treated as a _release_ access, i.e., the
65-
release memory operation cannot be observed to take place before any
66-
earlier memory operations on this RISC-V hart. If both the _aq_ and _rl_
67-
bits are set, the atomic memory operation is _sequentially consistent_
68-
and cannot be observed to happen before any earlier memory operations or
69-
after any later memory operations in the same RISC-V hart and to the
70-
same address domain.
71-
params:
72-
MISALIGNED_AMO:
73-
description: |
74-
whether or not the implementation supports misaligned atomics in main memory
75-
schema:
76-
type: boolean
77-
LRSC_RESERVATION_STRATEGY:
78-
description: |
79-
Strategy used to handle reservation sets.
61+
If both bits are clear, no additional ordering constraints are imposed
62+
on the atomic memory operation. If only the _aq_ bit is set, the atomic
63+
memory operation is treated as an _acquire_ access, i.e., no following
64+
memory operations on this RISC-V hart can be observed to take place
65+
before the acquire memory operation. If only the _rl_ bit is set, the
66+
atomic memory operation is treated as a _release_ access, i.e., the
67+
release memory operation cannot be observed to take place before any
68+
earlier memory operations on this RISC-V hart. If both the _aq_ and _rl_
69+
bits are set, the atomic memory operation is _sequentially consistent_
70+
and cannot be observed to happen before any earlier memory operations or
71+
after any later memory operations in the same RISC-V hart and to the
72+
same address domain.
73+
params:
74+
MISALIGNED_AMO:
75+
description: |
76+
whether or not the implementation supports misaligned atomics in main memory
77+
schema:
78+
type: boolean
79+
LRSC_RESERVATION_STRATEGY:
80+
description: |
81+
Strategy used to handle reservation sets.
8082
81-
* "reserve naturally-aligned 64-byte region": Always reserve the 64-byte block containing the LR/SC address
82-
* "reserve naturally-aligned 128-byte region": Always reserve the 128-byte block containing the LR/SC address
83-
* "reserve exactly enough to cover the access": Always reserve exactly the LR/SC access, and no more
84-
* "custom": Custom behavior, leading to an 'unpredictable' call on any LR/SC
85-
schema:
86-
type: string
87-
enum:
88-
- reserve naturally-aligned 64-byte region
89-
- reserve naturally-aligned 128-byte region
90-
- reserve exactly enough to cover the access
91-
- custom
92-
LRSC_FAIL_ON_VA_SYNONYM:
93-
description: |
94-
Whether or not an `sc.l`/`sc.d` will fail if its VA does not match the VA of the prior
95-
`lr.l`/`lr.d`, even if the physical address of the SC and LR are the same
96-
schema:
97-
type: boolean
98-
LRSC_MISALIGNED_BEHAVIOR:
99-
description: |
100-
What to do when an LR/SC address is misaligned and MISALIGNED_AMO == false.
83+
* "reserve naturally-aligned 64-byte region": Always reserve the 64-byte block containing the LR/SC address
84+
* "reserve naturally-aligned 128-byte region": Always reserve the 128-byte block containing the LR/SC address
85+
* "reserve exactly enough to cover the access": Always reserve exactly the LR/SC access, and no more
86+
* "custom": Custom behavior, leading to an 'unpredictable' call on any LR/SC
87+
schema:
88+
type: string
89+
enum:
90+
- reserve naturally-aligned 64-byte region
91+
- reserve naturally-aligned 128-byte region
92+
- reserve exactly enough to cover the access
93+
- custom
94+
LRSC_FAIL_ON_VA_SYNONYM:
95+
description: |
96+
Whether or not an `sc.l`/`sc.d` will fail if its VA does not match the VA of the prior
97+
`lr.l`/`lr.d`, even if the physical address of the SC and LR are the same
98+
schema:
99+
type: boolean
100+
LRSC_MISALIGNED_BEHAVIOR:
101+
description: |
102+
What to do when an LR/SC address is misaligned and MISALIGNED_AMO == false.
101103
102-
* 'always raise misaligned exception': self-explainitory
103-
* 'always raise access fault': self-explainitory
104-
* 'custom': Custom behavior; misaligned LR/SC may sometimes raise a misaligned exception and sometimes raise a access fault. Will lead to an 'unpredictable' call on any misaligned LR/SC access
105-
schema:
106-
type: string
107-
enum:
108-
- always raise misaligned exception
109-
- always raise access fault
110-
- custom
111-
LRSC_FAIL_ON_NON_EXACT_LRSC:
112-
description: |
113-
Whether or not a Store Conditional fails if its physical address and size do not
114-
exactly match the physical address and size of the last Load Reserved in program order
115-
(independent of whether or not the SC is in the current reservation set)
116-
schema:
117-
type: boolean
118-
MUTABLE_MISA_A:
119-
description: |
120-
When the `A` extensions is supported, indicates whether or not
121-
the extension can be disabled in the `misa.A` bit.
122-
schema:
123-
type: boolean
104+
* 'always raise misaligned exception': self-explainitory
105+
* 'always raise access fault': self-explainitory
106+
* 'custom': Custom behavior; misaligned LR/SC may sometimes raise a misaligned exception and sometimes raise a access fault. Will lead to an 'unpredictable' call on any misaligned LR/SC access
107+
schema:
108+
type: string
109+
enum:
110+
- always raise misaligned exception
111+
- always raise access fault
112+
- custom
113+
LRSC_FAIL_ON_NON_EXACT_LRSC:
114+
description: |
115+
Whether or not a Store Conditional fails if its physical address and size do not
116+
exactly match the physical address and size of the last Load Reserved in program order
117+
(independent of whether or not the SC is in the current reservation set)
118+
schema:
119+
type: boolean
120+
MUTABLE_MISA_A:
121+
description: |
122+
When the `A` extensions is supported, indicates whether or not
123+
the extension can be disabled in the `misa.A` bit.
124+
schema:
125+
type: boolean

‎arch/ext/B.yaml‎

Lines changed: 36 additions & 34 deletions
Original file line numberDiff line numberDiff line change
@@ -1,37 +1,39 @@
11
# yaml-language-server: $schema=../../schemas/ext_schema.json
22

3-
B:
4-
type: unprivileged
5-
long_name: Bitmanipulation instructions
6-
company:
7-
name: RISC-V International
8-
url: https://riscv.org
9-
doc_license:
10-
name: Creative Commons Attribution 4.0 International License
11-
url: https://creativecommons.org/licenses/by/4.0/
12-
versions:
13-
- version: "1.0.0"
14-
state: ratified
15-
ratification_date: 2024-04
16-
contributors:
17-
- name: Ved Shanbhogue
18-
email: [email protected]
19-
company: Rivos, Inc.
20-
url: https://drive.google.com/file/d/1SgLoasaBjs5WboQMaU3wpHkjUwV71UZn/view
21-
implies:
22-
- [Zba, "1.0.0"]
23-
- [Zbb, "1.0.0"]
24-
- [Zbs, "1.0.0"]
25-
description: |
26-
The B standard extension comprises instructions provided by the `Zba`, `Zbb`, and `Zbs` extensions.
3+
$schema: "ext_schema.json#"
4+
kind: extension
5+
name: B
6+
type: unprivileged
7+
long_name: Bitmanipulation instructions
8+
company:
9+
name: RISC-V International
10+
url: https://riscv.org
11+
doc_license:
12+
name: Creative Commons Attribution 4.0 International License
13+
url: https://creativecommons.org/licenses/by/4.0/
14+
versions:
15+
- version: "1.0.0"
16+
state: ratified
17+
ratification_date: 2024-04
18+
contributors:
19+
- name: Ved Shanbhogue
20+
email: [email protected]
21+
company: Rivos, Inc.
22+
url: https://drive.google.com/file/d/1SgLoasaBjs5WboQMaU3wpHkjUwV71UZn/view
23+
implies:
24+
- [Zba, "1.0.0"]
25+
- [Zbb, "1.0.0"]
26+
- [Zbs, "1.0.0"]
27+
description: |
28+
The B standard extension comprises instructions provided by the `Zba`, `Zbb`, and `Zbs` extensions.
2729
28-
Bit 1 of the `misa` register encodes the presence of the B standard extension. When `misa.B` is 1,
29-
the implementation supports the instructions provided by the `Zba`, `Zbb`, and `Zbs` extensions.
30-
When `misa.B` is 0, it indicates that the implementation may not support one or more of the
31-
`Zba`, `Zbb`, or `Zbs` extensions.
32-
params:
33-
MUTABLE_MISA_B:
34-
description: |
35-
Indicates whether or not the `B` extension can be disabled with the `misa.B` bit.
36-
schema:
37-
type: boolean
30+
Bit 1 of the `misa` register encodes the presence of the B standard extension. When `misa.B` is 1,
31+
the implementation supports the instructions provided by the `Zba`, `Zbb`, and `Zbs` extensions.
32+
When `misa.B` is 0, it indicates that the implementation may not support one or more of the
33+
`Zba`, `Zbb`, or `Zbs` extensions.
34+
params:
35+
MUTABLE_MISA_B:
36+
description: |
37+
Indicates whether or not the `B` extension can be disabled with the `misa.B` bit.
38+
schema:
39+
type: boolean

0 commit comments

Comments
 (0)