[PATCH] Add an ISA requirement section


atishp@...
 

On Thu, 2021-07-22 at 15:21 -0700, Andrew Waterman wrote:


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).
Makes sense.


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.
I will update the patch. Thanks.




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@...
 



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:
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.


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