Fix a typo and edit for clarity. (riscv#1914)

. Conversions narrowing to BF16 end up at BF16, not the target
  precision (which is the origin of the conversion).

. Capitalize an 'i' at sentence start.

. Remove repetition of C bit in *stateen0 not being custom state.

. Remove a misplaced 'of'.

Author: pmundkur

src/bfloat16.adoc

@@ -345,7 +345,7 @@ converting to FP32 and then converting from FP32 to the target
 precision. 
 Conversions narrowing to BF16 can be synthesized by first
 converting to FP32 through a series of halving steps and then
-converting from FP32 to the target precision. 
+converting from FP32 to BF16.
 As with the fused multiply-addition instruction described above,
 this method of converting values to BF16 can be off by 1-ulp 
 on some inputs for the RNE and RMM rounding modes.

src/smepmp.adoc

@@ -22,7 +22,7 @@ Terms:
 
 ==== Threat model
 
-However, there are no such mechanisms available on Machine mode in the current (v1.11) Privileged Spec. It is not possible for a PMP rule to be *enforced* only on non-Machine modes and *denied* on Machine mode, to only allow access to a memory region by less-privileged modes. it is only possible to have a *locked* rule that will be *enforced* on all modes, or a rule that will be *enforced* on non-Machine modes and be *ignored* by Machine mode. So for any physical memory region which is not protected with a Locked rule, Machine mode has unlimited access, including the ability to execute it.
+However, there are no such mechanisms available on Machine mode in the current (v1.11) Privileged Spec. It is not possible for a PMP rule to be *enforced* only on non-Machine modes and *denied* on Machine mode, to only allow access to a memory region by less-privileged modes. It is only possible to have a *locked* rule that will be *enforced* on all modes, or a rule that will be *enforced* on non-Machine modes and be *ignored* by Machine mode. So for any physical memory region which is not protected with a Locked rule, Machine mode has unlimited access, including the ability to execute it.
 
 Without being able to protect less-privileged modes from Machine mode, it is not possible to prevent the mentioned attack vector. This becomes even more important for RISC-V than on other architectures, since implementations are allowed where a hart only has Machine and User modes available, so the whole OS will run on Machine mode instead of the non-existent Supervisor mode. In such implementations the attack surface is greatly increased, and the same kind of attacks performed on Supervisor mode and mitigated through SMAP/SMEP, can be performed on Machine mode without any available mitigations. Even on implementations with Supervisor mode present attacks are still possible against the Firmware and/or the Secure Monitor running on Machine mode.
 

src/smstateen.adoc

@@ -227,8 +227,8 @@ read-only).
 ], config:{bits: 32, lanes: 2, hspace:1024}}
 ....
 
-The C bit controls access to any and all custom state. This bit is not custom
-state itself. The  C bit of these registers is not custom state itself; it is a
+The C bit controls access to any and all custom state.
+The C bit of these registers is not custom state itself; it is a
 standard field of a standard CSR, either `mstateen0`, `hstateen0`, or
 `sstateen0`.
 

src/zfinx.adoc

@@ -13,7 +13,7 @@ floating-point precisions.
 ====
 The F extension uses separate `f` registers for floating-point
 computation, to reduce register pressure and simplify the provision of
-register-file ports for wide superscalars. However, the additional of
+register-file ports for wide superscalars. However, the additional
 architectural state increases the minimal implementation cost. By
 eliminating the `f` registers, the Zfinx extension substantially reduces
 the cost of simple RISC-V implementations with floating-point