Date
1 - 5 of 5
[PATCH] Add an ISA requirement section
|
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 |
|
|
|
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 |
|
|
|
atishp@...
On Thu, 2021-07-22 at 01:17 -0700, Andrew Waterman wrote:
Thanks for adding this.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. -- 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: 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.
|
|
|
|
atishp@...
On Thu, 2021-07-22 at 15:21 -0700, Andrew Waterman wrote:
Makes sense. I will update the patch. Thanks. --coherent Regards, Atish |
|
|