From 86b11b083330f10646e16a35e0a12e8524524d26 Mon Sep 17 00:00:00 2001 From: Kevin Broch Date: Fri, 17 Jan 2025 09:13:01 -0800 Subject: [PATCH] WIP --- src/c-st-ext.adoc | 2 +- src/counters-f.adoc | 2 +- src/counters.adoc | 2 +- src/f-st-ext.adoc | 2 +- src/history.adoc | 8 ++++---- src/m-st-ext.adoc | 2 +- src/resources/riscv-spec.bib | 2 +- src/scalar-crypto.adoc | 2 +- 8 files changed, 11 insertions(+), 11 deletions(-) diff --git a/src/c-st-ext.adoc b/src/c-st-ext.adoc index ad0e57ebc..0be04a49a 100644 --- a/src/c-st-ext.adoc +++ b/src/c-st-ext.adoc @@ -197,7 +197,7 @@ _The standard RISC-V calling convention maps the most frequently used floating-point registers to registers `f8` to `f15`, which allows the same register decompression decoding as for integer register numbers._ ==== -((((register source spcifiers, c-ext)))) +((((register source specifiers, c-ext)))) The formats were designed to keep bits for the two register source specifiers in the same place in all instructions, while the destination register field can move. When the full 5-bit destination register diff --git a/src/counters-f.adoc b/src/counters-f.adoc index 4678d7825..304a78def 100644 --- a/src/counters-f.adoc +++ b/src/counters-f.adoc @@ -48,7 +48,7 @@ is that RDCYCLE is used for performance monitoring along with the other performance counters. In particular, where there is one hart/core, one would expect cycle-count/instructions-retired to measure CPI for a hart. -Cores don’t have to be exposed to software at all, and an implementor +Cores don’t have to be exposed to software at all, and an implementer might choose to pretend multiple harts on one physical core are running on separate cores with one hart/core, and provide separate cycle counters for each hart. This might make sense in a simple barrel diff --git a/src/counters.adoc b/src/counters.adoc index 7ec72108d..8236e4245 100644 --- a/src/counters.adoc +++ b/src/counters.adoc @@ -78,7 +78,7 @@ is that RDCYCLE is used for performance monitoring along with the other performance counters. In particular, where there is one hart/core, one would expect cycle-count/instructions-retired to measure CPI for a hart. -Cores don't have to be exposed to software at all, and an implementor +Cores don't have to be exposed to software at all, and an implementer might choose to pretend multiple harts on one physical core are running on separate cores with one hart/core, and provide separate cycle counters for each hart. This might make sense in a simple barrel diff --git a/src/f-st-ext.adoc b/src/f-st-ext.adoc index 88506d4b3..1da65f30e 100644 --- a/src/f-st-ext.adoc +++ b/src/f-st-ext.adoc @@ -196,7 +196,7 @@ standard, but this decision would have increased hardware cost. Moreover, since this feature is optional in the standard, it cannot be used in portable code. -Implementors are free to provide a NaN payload propagation scheme as a +Implementers are free to provide a NaN payload propagation scheme as a nonstandard extension enabled by a nonstandard operating mode. However, the canonical NaN scheme described above must always be supported and should be the default mode. ==== ''' diff --git a/src/history.adoc b/src/history.adoc index 7995d0169..beebb680f 100644 --- a/src/history.adoc +++ b/src/history.adoc @@ -36,7 +36,7 @@ sources of commercial ISA implementations, but who are prohibited from creating their own clean room implementations. We cannot guarantee that all RISC-V implementations will be free of third-party patent infringements, but we can guarantee we will not attempt to sue a RISC-V -implementor. +implementer. * *Commercial ISAs are only popular in certain market domains.* The most obvious examples at time of writing are that the ARM architecture is not well supported in the server space, and the Intel x86 architecture (or @@ -129,7 +129,7 @@ overall format of the manual date back to the T0 (Torrent-0) vector microprocessor project at UC Berkeley and ICSI, begun in 1992. T0 was a vector processor based on the MIPS-II ISA, with Krste Asanović as main architect and RTL designer, and Brian Kingsbury and Bertrand Irrisou as -principal VLSI implementors. David Johnson at ICSI was a major +principal VLSI implementers. David Johnson at ICSI was a major contributor to the T0 ISA design, particularly supervisor mode, and to the manual text. John Hauser also provided considerable feedback on the T0 ISA design. @@ -167,8 +167,8 @@ Scale infrastructure but the Maven ISA moved further away from the MIPS ISA variant defined in Scale, with a unified floating-point and integer register file. Maven was designed to support experimentation with alternative data-parallel accelerators. Yunsup Lee was the main -implementor of the various Maven vector units, while Rimas Avižienis was -the main implementor of the various Maven scalar units. Yunsup Lee and +implementer of the various Maven vector units, while Rimas Avižienis was +the main implementer of the various Maven scalar units. Yunsup Lee and Christopher Batten ported GCC to work with the new Maven ISA. Christopher Celio provided the initial definition of a traditional vector instruction set ("Flood") variant of Maven. diff --git a/src/m-st-ext.adoc b/src/m-st-ext.adoc index 1c036cb82..1b28984f2 100644 --- a/src/m-st-ext.adoc +++ b/src/m-st-ext.adoc @@ -119,7 +119,7 @@ We considered raising exceptions on integer divide by zero, with these exceptions causing a trap in most execution environments. However, this would be the only arithmetic trap in the standard ISA (floating-point exceptions set flags and write default values, but do not cause traps) -and would require language implementors to interact with the execution +and would require language implementers to interact with the execution environment's trap handlers for this case. Further, where language standards mandate that a divide-by-zero exception must cause an immediate control flow change, only a single branch instruction needs to diff --git a/src/resources/riscv-spec.bib b/src/resources/riscv-spec.bib index e0d541310..e89d33f47 100644 --- a/src/resources/riscv-spec.bib +++ b/src/resources/riscv-spec.bib @@ -750,7 +750,7 @@ @article{CDPA:16 % -% Block Cipher Specifiations +% Block Cipher Specifications % ----------------------------------------------------------------- @inproceedings{block:prince, diff --git a/src/scalar-crypto.adoc b/src/scalar-crypto.adoc index d72636483..3fe71cb22 100644 --- a/src/scalar-crypto.adoc +++ b/src/scalar-crypto.adoc @@ -3735,7 +3735,7 @@ A virtual source is not a physical entropy source but provides additional protection against covert channels, depletion attacks, and host identification in operating environments that can not be entirely trusted with direct access to a hardware resource. Despite limited trust, -implementors should try to guarantee that even such environments have +implementers should try to guarantee that even such environments have sufficient entropy available for secure cryptographic operations. A virtual source traps access to the `seed` CSR, emulates it, or