Generalize fence.tso instruction

[a4lg]

fence.tso instruction is encoded as a FENCE instruction with fm=1000, predecessor=RW, and successor=RW (as per the ISA Manual).

This commit generalizes fence.tso instruction to have unused rs1 and rd operands (shall be zero on standard software).

In this PR, fence.tso is encoded like fence and fence.i instructions (that have generalized forms on riscv-opcodes).

Not a Request: pause from Zihintntl

Note that pause instruction must not be edited like this because (quoting the ISA Manual),

PAUSE is encoded as a FENCE instruction with pred=W, succ=0, fm=0, rd=x0, and rs1=x0.

[codecov-commenter]

Codecov Report

Merging #135 (86cb748) into master (d2bbcb8) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #135   +/-   ##
=======================================
  Coverage   95.57%   95.57%           
=======================================
  Files           3        3           
  Lines         656      656           
=======================================
  Hits          627      627           
  Misses         29       29           

📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

[neelgala]

The spec says : The unused fields in the FENCE instructions—rs1 and rd—are reserved for finer-grain fences in future extensions.. So fence.tso should have those fields as 0 as per spec. The spec has reserved the unused encodings for future use.

[a4lg]

I must say that fence and fence.i instructions have those reserved fields encoded as variables.

Although they are reserved,

2.7 Memory Ordering Instructions

...
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 Table 2.2 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 non-reserved configurations.

Chapter 3: “Zifencei” Instruction-Fetch Fence, Version 2.0

...
The unused fields in the FENCE.I instruction, imm[11:0], 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.

it's not a bad idea to make them variable to safely ignore them without any illegal instruction fault (e.g. Spike is a base implementation and base implementations shall ignore those reserved fields/combinations).

[neelgala]

hmm.. I see the inconsistency now (thanks).... and I am going to let @aswaterman decide which way to go - we can either accept this or fix fence/fence.i accordingly.

[a4lg]

I don't recommend changing fence and fence.i (even if this is inconsistent) since it will cause an illegal instruction trap when reserved fence or fence.i is executed on Spike and it's against recommended behavior of RISC-V base implementations (as I quoted above). Because fence.tso is a subset of fence, not changing fence.tso is not harmful to Spike (despite that I think changing fence.tso is better).

So options I think is:

1. Change fence.tso as in this PR, or
2. Keep fence, fence.i and fence.tso as is.

[aswaterman]

This is technically correct, even if surprising.