Xjyuk

On intel IAPX 80286, as I recall from experience, the undocumented - officially unassigned - "opcode" position 0xF1 was actually decoded as an instruction-prefix, thus counting for maximum allowed instruction length (ten bytes), but otherwise not modifying the prefixed instruction : a "no operation" prefix, sort of. Now, what I have always wondered and could not assert lacking appropriate lab equipment ("logic analyzer" or a mere oscilloscope) : was F1h perhaps an 'alias' for the lock-prefix (F0h), or was it just ignored by the CPU (apart from counting for instruction length) ?

Note : we know that position 0xF1 of the opcode 'matrix' was later reused for a one-byte "int 1" opcode (not a prefix) starting with the i80386, that also was not documented until much later. This later conflicting assignment of the opcode position is not part of the here question.

According to an Intel document describing opcodes which don’t result in exception 6,

The 0F1H opcode is a prefix which performs no function. It counts like any other prefix towards the maximum instruction length. No restrictions apply to its execution.

The same document mentions explicitly when opcodes are aliases for others. I interpret the above as meaning that 0xF1 is not an alias for 0xF0. If it was, I would have hoped the locking behaviour would be mentioned.

However this 2010 post in comp.lang.asm.x86 does mention that 0xF1 is an alias for 0xF0, and that the only way to determine this is by testing it, since the Intel documentation is unreliable.

I don’t have a 286 handy to test this behaviour though. To test this on a real 80286, you’d need either a logic analyser (as you mention), or a protected-mode test program — since LOCK is a privileged prefix, if 0xF1 is an alias for it, it should generate a general protection fault if it’s used without the appropriate privilege. (On a 386 or later CPU, the test would be easier, since LOCK with an inappropriate instruction or operand generates an invalid opcode exception, but 0xF1 is different there.)