add missing Oxford commas (riscv#2169)

relates to riscv#2168

Signed-off-by: Kevin Broch <[email protected]>

Author: kbroch-rivosinc

src/bfloat16.adoc

@@ -154,7 +154,7 @@ by the format's smallest exponent value with a "0" integer bit and at least one
 in the trailing fractional bits are called subnormal numbers. Basically, the idea is there is
 a trade off of precision to support _gradual underflow_.
 
-All of the BF16 instructions in the extensions defined in this specification (i.e., Zfbfmin, Zvfbfmin
+All of the BF16 instructions in the extensions defined in this specification (i.e., Zfbfmin, Zvfbfmin,
 and Zvfbfwma) fully support subnormal numbers. That is, instructions are able to accept subnormal values as
 inputs and they can produce subnormal results.
 

src/mm-formal.adoc

@@ -637,7 +637,7 @@ instance)
 . <<reg_write, Register write>>
 . <<finish, Finish instruction>>
 
-Before, between and after the transitions above, any number of
+Before, between, and after the transitions above, any number of
 <<sail_interp, Pseudocode internal step>> transitions may appear. In addition, a <<fetch, Fetch instruction>> transition for fetching the
 instruction in the next program location will be available until it is
 taken.

src/vector-crypto.adoc

@@ -760,7 +760,7 @@ Likewise, `vstart` must be a multiple of `EGS=4`.
 ==== `Zvksed` - ShangMi Suite: SM4 Block Cipher
 
 Instructions for accelerating
-encryption, decryption and key-schedule
+encryption, decryption, and key-schedule
 functions of the SM4 block cipher.
 
 The SM4 block cipher is specified in _32907-2016: {SM4} Block Cipher Algorithm_

src/zc.adoc

@@ -57,7 +57,7 @@ The C extension is the superset of the following extensions:
 * Zcf if F is specified (RV32 only)
 * Zcd if D is specified
 
-As C defines the same instructions as Zca, Zcf and Zcd, the rule is that:
+As C defines the same instructions as Zca, Zcf, and Zcd, the rule is that:
 
 * C always implies Zca
 * C+F implies Zcf (RV32 only)

src/zpm.adoc

@@ -3,7 +3,7 @@
 
 === Introduction
 
-RISC-V Pointer Masking (PM) is a feature that, when enabled, causes the CPU to ignore the upper bits of the effective address (these terms will be defined more precisely in the Background section). This allows these bits to be used in whichever way the application chooses. The version of the extension being described here specifically targets **tag checks**: When an address is accessed, the tag stored in the masked bits can be compared against a range-based tag. This is used for dynamic safety checkers such as HWASAN cite:[HWASAN]. Such tools can be applied in all privilege modes (U, S and M).
+RISC-V Pointer Masking (PM) is a feature that, when enabled, causes the CPU to ignore the upper bits of the effective address (these terms will be defined more precisely in the Background section). This allows these bits to be used in whichever way the application chooses. The version of the extension being described here specifically targets **tag checks**: When an address is accessed, the tag stored in the masked bits can be compared against a range-based tag. This is used for dynamic safety checkers such as HWASAN cite:[HWASAN]. Such tools can be applied in all privilege modes (U, S, and M).
 
 HWASAN leverages tags in the upper bits of the address to identify memory errors such as use-after-free or buffer overflow errors. By storing a *pointer tag* in the upper bits of the address and checking it against a *memory tag* stored in a side table, it can identify whether a pointer is pointing to a valid location. Doing this without hardware support introduces significant overheads since the pointer tag needs to be manually removed for every conventional memory operation. Pointer masking support reduces these overheads.
 
@@ -268,7 +268,7 @@ Since pointer masking applies to the effective address only and does not affect
 
 ==== Interaction with Two-Stage Address Translation
 
-Guest physical addresses (GPAs) are 2 bits wider than the corresponding virtual address translation modes, resulting in additional address translation schemes Sv32x4, Sv39x4, Sv48x4 and Sv57x4 for translating guest physical addresses to supervisor physical addresses. When running with virtualization in VS/VU mode with `vsatp.MODE` = Bare, this means that those two bits may be subject to pointer masking, depending on `hgatp.MODE` and `senvcfg.PMM`/`henvcfg.PMM` (for VU/VS mode). If `vsatp.MODE` != BARE, this issue does *not* apply.
+Guest physical addresses (GPAs) are 2 bits wider than the corresponding virtual address translation modes, resulting in additional address translation schemes Sv32x4, Sv39x4, Sv48x4, and Sv57x4 for translating guest physical addresses to supervisor physical addresses. When running with virtualization in VS/VU mode with `vsatp.MODE` = Bare, this means that those two bits may be subject to pointer masking, depending on `hgatp.MODE` and `senvcfg.PMM`/`henvcfg.PMM` (for VU/VS mode). If `vsatp.MODE` != BARE, this issue does *not* apply.
 
 [NOTE]
 ====