Fetch Instruction/Category clarification

[AFOliveira]

I think that opcode change here makes it clear enough that FENCE instruction requires fm=0000 and given the previous wavedrom, I also think it is clear that there is room for further future uses.

@ThinkOpenly @aswaterman Do you think I should clarify the difference between Category vs Instruction more clearly?

Resolves #1782

[ThinkOpenly]

Not sure if it's best to post this here, or just open a PR with this content, but I tried to crisp up the text a bit with some consistent use of language and character attributes:

• I avoid "the FENCE instruction" in favor of "FENCE instructions" or "a FENCE instruction" (just all caps here, too).
• I capitalized "fence" when it was clearly referring to "FENCE instructions".
• I used FENCE when the referring to the FENCE instruction (with fm=0000).
• I put "with fm=0000" in paretheses when it was already associated with the FENCE instruction (with fm=0000) to covey that this was just to add clarity for something that should already be fairly clear. (Although using text attributes for clarity is not terribly accessible, perhaps?)
• I changed uses of FENCE to FENCE when it was referring to the class.
• I put all references to FENCE.TSO in backticks, since this is referring to a specific instruction (not the class).
• I put all references like FENCE RW,RW in backticks, since this is referring to a specific instruction.
• In this:

  many fm and predecessor/successor set settings in <> are also reserved for future use.
  I removed "in <>" because I couldn't make sense of that sentence otherwise.

• I replaced "normal fences" with "FENCE instructions (with fm=0000)", since it's really a reference to a specific instruction.

diff --git a/src/rv32.adoc b/src/rv32.adoc
index fc838707f521..c4380f3c61e1 100644
--- a/src/rv32.adoc
+++ b/src/rv32.adoc
@@ -792,7 +792,7 @@ include::images/wavedrom/mem-order.edn[]
 [[mem-order]]
 //.Memory ordering instructions
 
-The FENCE instruction is used to order device I/O and memory accesses as
+FENCE instructions are used to order device I/O and memory accesses as
 viewed by other RISC-V harts and external devices or coprocessors. Any
 combination of device input (I), device output (O), memory reads \(R),
 and memory writes (W) may be ordered with respect to any combination of
@@ -802,9 +802,9 @@ any operation in the _predecessor_ set preceding the FENCE.
 <<memorymodel>> provides a precise description
 of the RISC-V memory consistency model.
 
-The FENCE instruction also orders memory reads and writes made by the
+FENCE instructions also order memory reads and writes made by the
 hart as observed by memory reads and writes made by an external device.
-However, FENCE does not order observations of events made by an external
+However, FENCE instructions do not order observations of events made by an external
 device using any other signaling mechanism.
 
 [NOTE]
@@ -813,7 +813,7 @@ A device might observe an access to a memory location via some external
 communication mechanism, e.g., a memory-mapped control register that
 drives an interrupt signal to an interrupt controller. This
 communication is outside the scope of the FENCE ordering mechanism and
-hence the FENCE instruction can provide no guarantee on when a change in
+hence FENCE instructions can provide no guarantee on when a change in
 the interrupt signal is visible to the interrupt controller. Specific
 devices might provide additional ordering guarantees to reduce software
 overhead but those are outside the scope of the RISC-V memory model.
@@ -827,7 +827,7 @@ memory-mapped I/O devices will typically be accessed with uncached loads
 and stores that are ordered using the I and O bits rather than the R and
 W bits. Instruction-set extensions might also describe new I/O
 instructions that will also be ordered using the I and O bits in a
-FENCE.
+FENCE instruction.
 
 [[fm]]
 [float="center",align="center",cols="^1,^1,<3",options="header"]
@@ -839,11 +839,11 @@ FENCE.
 2+|_other_ |_Reserved for future use._
 |===
 
-The fence mode field _fm_ defines the semantics of the `FENCE`. A `FENCE`
-with _fm_=`0000` orders all memory operations in its predecessor set
+The FENCE mode field _fm_ defines the semantics of the FENCE instruction. A `FENCE`
+(with _fm_=`0000`) orders all memory operations in its predecessor set
 before all memory operations in its successor set.
 
-The `FENCE.TSO` instruction is encoded as a `FENCE` instruction
+A `FENCE.TSO` instruction is encoded as a FENCE instruction
 with _fm_=`1000`, _predecessor_=`RW`, and _successor_=`RW`. `FENCE.TSO` orders
 all load operations in its predecessor set before all memory operations
 in its successor set, and all store operations in its predecessor set
@@ -853,17 +853,17 @@ store operations in the `FENCE.TSO's` predecessor set unordered with
 
 [NOTE]
 ====
-Because FENCE RW,RW imposes a superset of the orderings that FENCE.TSO
-imposes, it is correct to ignore the _fm_ field and implement FENCE.TSO as FENCE RW,RW.
+Because `FENCE RW,RW` imposes a superset of the orderings that `FENCE.TSO`
+imposes, it is correct to ignore the _fm_ field and implement `FENCE.TSO` as `FENCE RW,RW`.
 ====
 
-The unused fields in the `FENCE` instructions--_rs1_ and _rd_--are reserved
+The unused fields in the FENCE instructions--_rs1_ and _rd_--are reserved
 for finer-grain fences in future extensions. For forward compatibility,
 base implementations shall ignore these fields, and standard software
 shall zero these fields. Likewise, many _fm_ and predecessor/successor
-set settings in <<fm>> are also reserved for future use.
+set settings are also reserved for future use.
 Base implementations shall treat all such reserved configurations as
-normal fences with _fm_=0000, and standard software shall use only
+`FENCE` instructions (with _fm_=`0000`), and standard software shall use only
 non-reserved configurations.

[AFOliveira]

I converted this to draft until we figure this.

@ThinkOpenly Could you commit those changes in any repo so I can cherry pick them? Or maybe we could do the PR from a repo we both have acess to? Or last case scenario I can just copy your commit and give credit in commit message, maybe co-authoring? I honestly don't know how to procede, how do you think it is preferable to do this?

[aswaterman]

The changes other than the instruction encoding look OK to me.

[ThinkOpenly]

@ThinkOpenly Could you commit those changes in any repo so I can cherry pick them? Or maybe we could do the PR from a repo we both have acess to?

https://github.com/ThinkOpenly/riscv-isa-manual/tree/FENCEd-in (branch), or the specific commit:
ThinkOpenly@11ddabf

It's fairly independent of your changes, except perhaps the last hunk, so I could create an independent PR, or you can cherry-pick. I'm flexible.

[aswaterman]

This version LGTM, thanks.