Date
1 - 5 of 5
[PATCH] Add an ISA requirement section
atishp@...
On Thu, 2021-07-22 at 15:21 -0700, Andrew Waterman wrote:
Regards,
Atish
Makes sense.
On Thu, Jul 22, 2021 at 12:12 PM Atish Patra <atish.patra@...>
wrote:On Thu, 2021-07-22 at 01:17 -0700, Andrew Waterman wrote:Thanks for adding this.requires
For systems that support little-endian, the ISA spec alreadythat mstatus.MBE be reset to 0. Furthermore, the ISA spec doessince
not
permit hardwiring SBE or UBE to a value that MBE does not
support.
(And of course the reset values of SBE and UBE are immaterial,they don't affect M-mode software and M-mode software mustinitializethe rest of mstatus prior to entering S-mode or U-mode.)come
If we combine all of these facts, we can replace the following
sentence
Platforms must fully support Little-Endian operation and mustup in this mode of operation after power-on resetok. I will update it. Just a suggestion:
with the more precise constraint
Implementations must not hardwire the mstatus.MBE field to 1.
Is it better to say what must be supported rather what is not and
be
more verbose? Something like this:
Platforms is allowed to operate only in little-endian mode i.e.
implementations must hardwire the mstatus.MBE field to 0.
The way we are viewing this from the PrivArch side is that the ISA
spec lays out the legal options, and in this document, we constrain
the optionality. Following that pattern, we should generally only
list the new constraints (i.e. indicate what optionality is not
valid).
I will update the patch. Thanks.
However, as a compromise, we could be more verbose in telegraphing
the intent of the constraint:
Implementations must support little-endianness: i.e., they must not
hardwire the mstatus.MBE field to 1.
--coherent
and we will still obtain the desired result.
On Thu, Jul 22, 2021 at 1:00 AM Atish Patra <atish.patra@...>
wrote:There are few ISA level requirements/strong recommendations
that
platform
should follow. Create an new subsection to contain all these
requirements.
Move the user-level requirements from user.doc to here as well.
Signed-off-by: Atish Patra <atish.patra@...>
---
riscv-platform-spec.adoc | 11 +++++++++++
user-level.adoc | 17 -----------------
2 files changed, 11 insertions(+), 17 deletions(-)
delete mode 100644 user-level.adoc
diff --git a/riscv-platform-spec.adoc b/riscv-platform-
spec.adoc
index 394304bd6778..1f5b29a0200b 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -115,6 +115,17 @@ The M platform has the following
extensions:
** All hart PMA regions for main memory must be marked as
coherent.
** Memory accesses by I/O masters can be coherent or non-alignedwith respect
to all hart-related caches.
+* ISA Requirements
+** Within main-memory regions, aligned instruction fetch must
be
atomic, up to
+ the smaller of ILEN and XLEN bits. In particular, if anattempts4-
byte word
+ is stored with the `sw` instruction, then any processoroldto execute
+ that word, the processor either fetches the newly stored
word,
or
some previous
+ value stored to that location. (That is, the fetched
instruction
is not an
+ unpredictable value, nor is it a hybrid of the bytes of thealignedand new
+ values.)
+** Platforms must fully support Little-Endian operation and
must
come
+up in this mode of operation after power-on reset.
+** User-mode programs should not execute the `fence.i`
instruction.
==== PMU
diff --git a/user-level.adoc b/user-level.adoc
deleted file mode 100644
index 2742d98acaac..000000000000
--- a/user-level.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-// SPDX-License-Indentifer: CC-BY-4.0
-//
-// user-level.adoc: original User Level Platform content
-//
-// This is material from the very first draft of the spec.
-//
-
-## User-Level Platform
-
-* Within main-memory regions, aligned instruction fetch must
be
atomic, up to
- the smaller of ILEN and XLEN bits. In particular, if anattempts4-byte word
- is stored with the `sw` instruction, then any processoroldto execute
- that word, the processor either fetches the newly stored
word,
or
some previous
- value stored to that location. (That is, the fetched
instruction
is not an
- unpredictable value, nor is it a hybrid of the bytes of theand new
- values.)
-
Regards,
Atish
andrew@...
On Thu, Jul 22, 2021 at 12:12 PM Atish Patra <atish.patra@...> wrote:
On Thu, 2021-07-22 at 01:17 -0700, Andrew Waterman wrote:
> Thanks for adding this.
>
> For systems that support little-endian, the ISA spec already requires
> that mstatus.MBE be reset to 0. Furthermore, the ISA spec does not
> permit hardwiring SBE or UBE to a value that MBE does not support.
> (And of course the reset values of SBE and UBE are immaterial, since
> they don't affect M-mode software and M-mode software must initialize
> the rest of mstatus prior to entering S-mode or U-mode.)
>
> If we combine all of these facts, we can replace the following
> sentence
>
> Platforms must fully support Little-Endian operation and must come
> up in this mode of operation after power-on reset
>
> with the more precise constraint
>
> Implementations must not hardwire the mstatus.MBE field to 1.
ok. I will update it. Just a suggestion:
Is it better to say what must be supported rather what is not and be
more verbose? Something like this:
Platforms is allowed to operate only in little-endian mode i.e.
implementations must hardwire the mstatus.MBE field to 0.
The way we are viewing this from the PrivArch side is that the ISA spec lays out the legal options, and in this document, we constrain the optionality. Following that pattern, we should generally only list the new constraints (i.e. indicate what optionality is not valid).
However, as a compromise, we could be more verbose in telegraphing the intent of the constraint:
Implementations must support little-endianness: i.e., they must not hardwire the mstatus.MBE field to 1.
>
> and we will still obtain the desired result.
>
> On Thu, Jul 22, 2021 at 1:00 AM Atish Patra <atish.patra@...>
> wrote:
> > There are few ISA level requirements/strong recommendations that
> > platform
> > should follow. Create an new subsection to contain all these
> > requirements.
> > Move the user-level requirements from user.doc to here as well.
> >
> > Signed-off-by: Atish Patra <atish.patra@...>
> > ---
> > riscv-platform-spec.adoc | 11 +++++++++++
> > user-level.adoc | 17 -----------------
> > 2 files changed, 11 insertions(+), 17 deletions(-)
> > delete mode 100644 user-level.adoc
> >
> > diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
> > index 394304bd6778..1f5b29a0200b 100644
> > --- a/riscv-platform-spec.adoc
> > +++ b/riscv-platform-spec.adoc
> > @@ -115,6 +115,17 @@ The M platform has the following extensions:
> > ** All hart PMA regions for main memory must be marked as
> > coherent.
> > ** Memory accesses by I/O masters can be coherent or non-coherent
> > with respect
> > to all hart-related caches.
> > +* ISA Requirements
> > +** Within main-memory regions, aligned instruction fetch must be
> > atomic, up to
> > + the smaller of ILEN and XLEN bits. In particular, if an aligned
> > 4-
> > byte word
> > + is stored with the `sw` instruction, then any processor attempts
> > to execute
> > + that word, the processor either fetches the newly stored word,
> > or
> > some previous
> > + value stored to that location. (That is, the fetched
> > instruction
> > is not an
> > + unpredictable value, nor is it a hybrid of the bytes of the old
> > and new
> > + values.)
> > +** Platforms must fully support Little-Endian operation and must
> > come
> > +up in this mode of operation after power-on reset.
> > +** User-mode programs should not execute the `fence.i`
> > instruction.
> >
> >
> > ==== PMU
> > diff --git a/user-level.adoc b/user-level.adoc
> > deleted file mode 100644
> > index 2742d98acaac..000000000000
> > --- a/user-level.adoc
> > +++ /dev/null
> > @@ -1,17 +0,0 @@
> > -// SPDX-License-Indentifer: CC-BY-4.0
> > -//
> > -// user-level.adoc: original User Level Platform content
> > -//
> > -// This is material from the very first draft of the spec.
> > -//
> > -
> > -## User-Level Platform
> > -
> > -* Within main-memory regions, aligned instruction fetch must be
> > atomic, up to
> > - the smaller of ILEN and XLEN bits. In particular, if an aligned
> > 4-byte word
> > - is stored with the `sw` instruction, then any processor attempts
> > to execute
> > - that word, the processor either fetches the newly stored word,
> > or
> > some previous
> > - value stored to that location. (That is, the fetched
> > instruction
> > is not an
> > - unpredictable value, nor is it a hybrid of the bytes of the old
> > and new
> > - values.)
> > -
--
Regards,
Atish
atishp@...
On Thu, 2021-07-22 at 01:17 -0700, Andrew Waterman wrote:
Is it better to say what must be supported rather what is not and be
more verbose? Something like this:
Platforms is allowed to operate only in little-endian mode i.e.
implementations must hardwire the mstatus.MBE field to 0.
Regards,
Atish
Thanks for adding this.ok. I will update it. Just a suggestion:
For systems that support little-endian, the ISA spec already requires
that mstatus.MBE be reset to 0. Furthermore, the ISA spec does not
permit hardwiring SBE or UBE to a value that MBE does not support.
(And of course the reset values of SBE and UBE are immaterial, since
they don't affect M-mode software and M-mode software must initialize
the rest of mstatus prior to entering S-mode or U-mode.)
If we combine all of these facts, we can replace the following
sentence
Platforms must fully support Little-Endian operation and must come
up in this mode of operation after power-on reset
with the more precise constraint
Implementations must not hardwire the mstatus.MBE field to 1.
Is it better to say what must be supported rather what is not and be
more verbose? Something like this:
Platforms is allowed to operate only in little-endian mode i.e.
implementations must hardwire the mstatus.MBE field to 0.
--
and we will still obtain the desired result.
On Thu, Jul 22, 2021 at 1:00 AM Atish Patra <atish.patra@...>
wrote:There are few ISA level requirements/strong recommendations that
platform
should follow. Create an new subsection to contain all these
requirements.
Move the user-level requirements from user.doc to here as well.
Signed-off-by: Atish Patra <atish.patra@...>
---
riscv-platform-spec.adoc | 11 +++++++++++
user-level.adoc | 17 -----------------
2 files changed, 11 insertions(+), 17 deletions(-)
delete mode 100644 user-level.adoc
diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 394304bd6778..1f5b29a0200b 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -115,6 +115,17 @@ The M platform has the following extensions:
** All hart PMA regions for main memory must be marked as
coherent.
** Memory accesses by I/O masters can be coherent or non-coherent
with respect
to all hart-related caches.
+* ISA Requirements
+** Within main-memory regions, aligned instruction fetch must be
atomic, up to
+ the smaller of ILEN and XLEN bits. In particular, if an aligned
4-
byte word
+ is stored with the `sw` instruction, then any processor attempts
to execute
+ that word, the processor either fetches the newly stored word,
or
some previous
+ value stored to that location. (That is, the fetched
instruction
is not an
+ unpredictable value, nor is it a hybrid of the bytes of the old
and new
+ values.)
+** Platforms must fully support Little-Endian operation and must
come
+up in this mode of operation after power-on reset.
+** User-mode programs should not execute the `fence.i`
instruction.
==== PMU
diff --git a/user-level.adoc b/user-level.adoc
deleted file mode 100644
index 2742d98acaac..000000000000
--- a/user-level.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-// SPDX-License-Indentifer: CC-BY-4.0
-//
-// user-level.adoc: original User Level Platform content
-//
-// This is material from the very first draft of the spec.
-//
-
-## User-Level Platform
-
-* Within main-memory regions, aligned instruction fetch must be
atomic, up to
- the smaller of ILEN and XLEN bits. In particular, if an aligned
4-byte word
- is stored with the `sw` instruction, then any processor attempts
to execute
- that word, the processor either fetches the newly stored word,
or
some previous
- value stored to that location. (That is, the fetched
instruction
is not an
- unpredictable value, nor is it a hybrid of the bytes of the old
and new
- values.)
-
Regards,
Atish
andrew@...
Thanks for adding this.
For systems that support little-endian, the ISA spec already requires that mstatus.MBE be reset to 0. Furthermore, the ISA spec does not permit hardwiring SBE or UBE to a value that MBE does not support. (And of course the reset values of SBE and UBE are immaterial, since they don't affect M-mode software and M-mode software must initialize the rest of mstatus prior to entering S-mode or U-mode.)
If we combine all of these facts, we can replace the following sentence
Platforms must fully support Little-Endian operation and must come up in this mode of operation after power-on reset
with the more precise constraint
Implementations must not hardwire the mstatus.MBE field to 1.
and we will still obtain the desired result.
On Thu, Jul 22, 2021 at 1:00 AM Atish Patra <atish.patra@...> wrote:
There are few ISA level requirements/strong recommendations that platform
should follow. Create an new subsection to contain all these requirements.
Move the user-level requirements from user.doc to here as well.
Signed-off-by: Atish Patra <atish.patra@...>
---
riscv-platform-spec.adoc | 11 +++++++++++
user-level.adoc | 17 -----------------
2 files changed, 11 insertions(+), 17 deletions(-)
delete mode 100644 user-level.adoc
diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 394304bd6778..1f5b29a0200b 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -115,6 +115,17 @@ The M platform has the following extensions:
** All hart PMA regions for main memory must be marked as coherent.
** Memory accesses by I/O masters can be coherent or non-coherent with respect
to all hart-related caches.
+* ISA Requirements
+** Within main-memory regions, aligned instruction fetch must be atomic, up to
+ the smaller of ILEN and XLEN bits. In particular, if an aligned 4-byte word
+ is stored with the `sw` instruction, then any processor attempts to execute
+ that word, the processor either fetches the newly stored word, or some previous
+ value stored to that location. (That is, the fetched instruction is not an
+ unpredictable value, nor is it a hybrid of the bytes of the old and new
+ values.)
+** Platforms must fully support Little-Endian operation and must come
+up in this mode of operation after power-on reset.
+** User-mode programs should not execute the `fence.i` instruction.
==== PMU
diff --git a/user-level.adoc b/user-level.adoc
deleted file mode 100644
index 2742d98acaac..000000000000
--- a/user-level.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-// SPDX-License-Indentifer: CC-BY-4.0
-//
-// user-level.adoc: original User Level Platform content
-//
-// This is material from the very first draft of the spec.
-//
-
-## User-Level Platform
-
-* Within main-memory regions, aligned instruction fetch must be atomic, up to
- the smaller of ILEN and XLEN bits. In particular, if an aligned 4-byte word
- is stored with the `sw` instruction, then any processor attempts to execute
- that word, the processor either fetches the newly stored word, or some previous
- value stored to that location. (That is, the fetched instruction is not an
- unpredictable value, nor is it a hybrid of the bytes of the old and new
- values.)
-
--
2.31.1
atishp@...
There are few ISA level requirements/strong recommendations that platform
should follow. Create an new subsection to contain all these requirements.
Move the user-level requirements from user.doc to here as well.
Signed-off-by: Atish Patra <atish.patra@...>
---
riscv-platform-spec.adoc | 11 +++++++++++
user-level.adoc | 17 -----------------
2 files changed, 11 insertions(+), 17 deletions(-)
delete mode 100644 user-level.adoc
diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 394304bd6778..1f5b29a0200b 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -115,6 +115,17 @@ The M platform has the following extensions:
** All hart PMA regions for main memory must be marked as coherent.
** Memory accesses by I/O masters can be coherent or non-coherent with respect
to all hart-related caches.
+* ISA Requirements
+** Within main-memory regions, aligned instruction fetch must be atomic, up to
+ the smaller of ILEN and XLEN bits. In particular, if an aligned 4-byte word
+ is stored with the `sw` instruction, then any processor attempts to execute
+ that word, the processor either fetches the newly stored word, or some previous
+ value stored to that location. (That is, the fetched instruction is not an
+ unpredictable value, nor is it a hybrid of the bytes of the old and new
+ values.)
+** Platforms must fully support Little-Endian operation and must come
+up in this mode of operation after power-on reset.
+** User-mode programs should not execute the `fence.i` instruction.
==== PMU
diff --git a/user-level.adoc b/user-level.adoc
deleted file mode 100644
index 2742d98acaac..000000000000
--- a/user-level.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-// SPDX-License-Indentifer: CC-BY-4.0
-//
-// user-level.adoc: original User Level Platform content
-//
-// This is material from the very first draft of the spec.
-//
-
-## User-Level Platform
-
-* Within main-memory regions, aligned instruction fetch must be atomic, up to
- the smaller of ILEN and XLEN bits. In particular, if an aligned 4-byte word
- is stored with the `sw` instruction, then any processor attempts to execute
- that word, the processor either fetches the newly stored word, or some previous
- value stored to that location. (That is, the fetched instruction is not an
- unpredictable value, nor is it a hybrid of the bytes of the old and new
- values.)
-
--
2.31.1
should follow. Create an new subsection to contain all these requirements.
Move the user-level requirements from user.doc to here as well.
Signed-off-by: Atish Patra <atish.patra@...>
---
riscv-platform-spec.adoc | 11 +++++++++++
user-level.adoc | 17 -----------------
2 files changed, 11 insertions(+), 17 deletions(-)
delete mode 100644 user-level.adoc
diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 394304bd6778..1f5b29a0200b 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -115,6 +115,17 @@ The M platform has the following extensions:
** All hart PMA regions for main memory must be marked as coherent.
** Memory accesses by I/O masters can be coherent or non-coherent with respect
to all hart-related caches.
+* ISA Requirements
+** Within main-memory regions, aligned instruction fetch must be atomic, up to
+ the smaller of ILEN and XLEN bits. In particular, if an aligned 4-byte word
+ is stored with the `sw` instruction, then any processor attempts to execute
+ that word, the processor either fetches the newly stored word, or some previous
+ value stored to that location. (That is, the fetched instruction is not an
+ unpredictable value, nor is it a hybrid of the bytes of the old and new
+ values.)
+** Platforms must fully support Little-Endian operation and must come
+up in this mode of operation after power-on reset.
+** User-mode programs should not execute the `fence.i` instruction.
==== PMU
diff --git a/user-level.adoc b/user-level.adoc
deleted file mode 100644
index 2742d98acaac..000000000000
--- a/user-level.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-// SPDX-License-Indentifer: CC-BY-4.0
-//
-// user-level.adoc: original User Level Platform content
-//
-// This is material from the very first draft of the spec.
-//
-
-## User-Level Platform
-
-* Within main-memory regions, aligned instruction fetch must be atomic, up to
- the smaller of ILEN and XLEN bits. In particular, if an aligned 4-byte word
- is stored with the `sw` instruction, then any processor attempts to execute
- that word, the processor either fetches the newly stored word, or some previous
- value stored to that location. (That is, the fetched instruction is not an
- unpredictable value, nor is it a hybrid of the bytes of the old and new
- values.)
-
--
2.31.1