Fence.tso is not pseudo for Fence

[AFOliveira]

Currently UDB specified fence.tso as pseudo-instructions under fence.yaml. However, this is not the case and fence.tso should have a separate file for it.

I believe this is the specified like this because of riscv-opcodes, but the only reason riscv-opcodes specified it like that is it not possible to support for both on current riscv-opcodes format.

Context:
riscv/riscv-opcodes#330
riscv/riscv-isa-manual#1782 (comment)

[ThinkOpenly]

fence.tso should have a separate file for it.

Probably so. It'll make a bit of a mess because you'll need to exclude the specific FENCE.TSO encoding from the FENCE encoding.

[dhower-qc]

Agree. In terms of encoding, this is captured by the hints key (I might not have that in main yet; it's used by the ISS decoder). Maybe there is a better key name?

fence.yaml:

# ...
hints:
  - { $ref: "inst/I/fence.tso.yaml" }
# ...

fence.tso.yaml:

# full fence.tso instruction

[AFOliveira]

I can't comprehend why to encode fence.tso as hint. Do they need to be connected at all? I think FENCE is described in the ISA both as a category of intructions (everything related to FENCEs) and as just an instruction FENCE.

I think it kind of acts the same way as the funct3/funct7 fields for Register-Register operations

Can't we remove the fm field from fence as a variable field and just describe it as 0000 for FENCE and 0001 for FENCE.TSO or would that have any further implications?

[ThinkOpenly]

How do we represent "reserved" values for which there is a "shall" in the ISA spec:

Likewise, many _fm_ [...] settings [...] are also reserved for future use. Base implementations shall treat all such reserved configurations as normal fences with fm=0000

Can't we remove the fm field from fence as a variable field and just describe it as 0000 for FENCE and 0001 for FENCE.TSO or would that have any further implications?

That's actually what the Sail code does:

mapping clause encdec = FENCE(pred, succ)
  <-> 0b0000 @ pred @ succ @ 0b00000 @ 0b000 @ 0b00000 @ 0b0001111
[...]
mapping clause encdec = FENCE_TSO(pred, succ)
  <-> 0b1000 @ pred @ succ @ 0b00000 @ 0b000 @ 0b00000 @ 0b0001111

I note that you used 0001, when the spec defines FENCE.TSO with fm=0b1000, but then I noticed that the IDL does the same (0001):

  if (fm == 1) {
    if (pred == 0x3 && succ == 0x3) {
      # this is a fence.tso instruction
      is_fence_tso = true;
    }
  }

Is the IDL code incorrect there? If we force FENCE to have fm=0b0000, then all the tests for values of fm go away?

[AFOliveira]

LLVM also represents fm as a hardcoded value. I re-opened my issue on the ISA manual to see if I can get clarification on this (riscv/riscv-isa-manual#1782 (comment))

I was wrong and I think you caught an IDL error. Indeed, correct value is described in the ISA as fm=0b1000

[dhower-qc]

Yep, that's an IDL bug.