Steven Seagal wrote:
The documentation states:
Code: Select all
If Supervisor State
Then Immediate Data -> SR; STOP
You could interpret it as "test Privilege once, if OK put Data in SR and wait".
I'm surprised that privilege is tested at each iteration.
Not exactly. They are two separate things. That seudocode only documents that STOP is a privileged instruction. That doesn't mean that clearing the S flag would trigger a privilege violation. Other instructions that modify the SR show the same seudocode, yet they don't trigger a priv violation exception if they clear the S flag.
In the manual I have, there is an explicit note that clearing the S flag could provoke an exception. For some reason they removed that note on later versions of the manual. It is possible that the omission is intentional because it depends on the microcode. And conceivable (have no way to test it), it behaves different in other CPU32 processors.
npomarede wrote:It doesn't test at each iteration, because if new value is wrong at start there will be no iteration at all, only a privilege exception.
Actually it is (almost) exactly the other way around. It tests (sort of, see below) at each iteration and, strange as it might sound, there are multiple iterations even if the new value clears the S flag ...
The instruction doesn't explicitly test if the new value would clear the S flag or not. That would be too expensive to implement at the microcode. What happens is that STOP does set the SR regardless. And in later iterations, because now the processor is in User mode, a priv violation exception is triggered. Not by the microcode, but by the same logic that checks for priv violations whenever starting any instruction.
It is possible that this is an incidental, and not by design, consequence of the microcode implementation. Conceivable it is different in later processors.