Consider MODE-SWITCH for one instruction, then switch back

[tariqkurd-repo]

A neat way of simplifying mode switch sequences which typically

C.MODESW ; <op>; C.MODESW

would be to have an instruction which switches for one instruction only, like the non-temporal hint instructions. This would allow the sequence above to be expressed without the second C.MODESW.

The sequence reduces to (using an invented mnemonic name):

C.MODESWO; <op>

The value will depend on the frequency of these sequences executing.

[jrtc27]

The non-temporal hint only set transient state, that’s lost on a trap. That is, if the load/store traps, xepc points to the load/store, and there is no architectural state indicating it was a non-temporal load/store, so when you xret you execute a normal unhinted load/store. This is a bit dodgy but technically not a problem, since non-temporal hints are just hints attempting to inform the microarchitecture about how to achieve the best performance. But that’s not the case with mode switching; the instructions are architecturally different. This means you would have to have architectural state, saved and restored when trapping, somewhere indicating that you are executing a single instruction in a different mode (and in some edge cases would have to have the OS clear it). This to me makes it not something to pursue.

[tariqkurd-repo]

yes - this is true - it does imply hidden state between the instructions which is unfortunate. It's not a hint like the non-temporal one, it's a real change.

[arichardson]

I could see this being useful to reduce code size (if such patterns end up being common), but to avoid potential races it would effectively require mandatory fusion of instructions. This would basically turn this proposal into a x86-ish "cap prefix"?

[tariqkurd-repo]

this will be tricky to implement, as returning to the instruction after the c.modesw0 won't know which mode to execute in