Add `pause` instruction from Zihintpause extension

[jordancarlin]

The Zihintpause.yaml extension yaml exists, but the pause instruction is not defined in the database yet. It should be defined as a hint of fence.

[jordancarlin]

Looking closer, this is defined as a pseudoinstruction in fence.yaml and the operation field handles it appropriately. This is not exposed to the generators though, so the instruction does not appear in the outputs like the SystemVerilog header from #1090.

The prefetch instructions from the Zicbop extension defined in ori.yaml have the same issue.

[ThinkOpenly]

What would be the preferred way to expose HINTs/pseudoinstructions? Exactly like regular instructions?

[jordancarlin]

What would be the preferred way to expose HINTs/pseudoinstructions? Exactly like regular instructions?

I think we need to be careful to separate HINTs and pseudoinstructions in this conversation. HINTs are unique instructions specified in the ISA manual with behavior that is different from any other instruction, while pseudoinstructions are alternative mnemonics that map to one (or more) existing instructions and may or may not be explicitly defined in the ISA manual.

riscv-opcodes includes both just like regular instructions in its generated artifacts, but I'm not convinced that is the best choice for pseudoinstructions.

Focusing on HINTs for now (which I think are higher priority since they are unique instructions), I think they should show up just like other instructions in the generated outputs. For example, the C or SystemVerilog headers should include their encodings in the list of instructions. It is likely that systems consuming these outputs will want to do something different with a pause instruction vs. a fence instruction, so they need to be able to distinguish between them.

In terms of representation within the database, I would argue that they should be their own YAML file just like any other instruction. This gives them their own operation field (instead of special casing particular encodings in their base instruction) and makes their encoding immediately apparent and easy to extract from the database. They should probably have an additional key indicating which instruction they override for the sake of the resolution step.

Thoughts?

[jordancarlin]

Looks like there was relevant discussion about this in #732 and #455.

[ThinkOpenly]

I'm not against pushing actual "hints" to their own independent YAML files. You make a good point that hints can kinda do whatever they want, completely unrelated to the "base" encoding, and stuffing all of those into a single operation() method seems to offer little value with the disadvantage of a big case statement with orthogonal code.

I don't think the current schema/infrastructure can handle this, based somewhat on the challenges I hit with sspush/sspopchk (#1061).

[jordancarlin]

Maybe we drop the not key from the parent instruction and instead have a hint_of or overrides field in the hint instruction. Then instead of confirming that there are no overlapping encodings, the database can actually enforce that they hint has an overlapping encoding with its parent. This overrides field can also be used by the ISS to ensure it checks if an instruction matches that hint encoding before checking the parent instruction encoding.