Function:

MOV Moves data in and out of (special) registers and memory.

Some _very early_ 88 and 86 processors do not disable interrupts following
a MOV sreg,reg. This causes them to crash when an interrupt uses the stack
between MOV SS,reg and MOV SP,op. These versions carry a copyright message
for 1978 on the package. Later, corrected revisions, carry both 1978 and
1981 as the copyright year.
Normally interrupts would be disabled between the move to SS and execution
of the instruction following it on 88 and 86es. A workaround is to manually
disable the interrupts when reloading SS. The 286 and higher processors only
disable interrupts after a MOV SS, in contrast to earlier CPUs, including
the NECs, who do this with all MOV sreg,op instructions.

An unsolvable problem occurs when an unmaskable interrupt or exception
takes place while executing the instruction pair on an old 88 or 86.
There are conflicting messages though about this type of interrupts having
no effect on the bug.

On the 86 and 88, but not on the C-MOS versions 80C86 and 80C88, the
instruction MOV CS,op is valid and causes an unconditional jump.
The C-MOS versions, as well as the NEC V20 and V30 ignore this coding.
This may also be the case on the 186 but has not been tested.
The 286+ CPUs consider CS an invalid operand for this instruction and
generate exception 6 (Invalid opcode).
The opcode for the MOV CS,op is: 8e [mod:001:r/m] See also <POP CS>.

On some 386es, random breakpoint breaks occur from the debug registers
D0-D3 when a MOV from CR3, TR6 or TR7 is executed. This will continue until
after a jump instruction is executed. The actual contexts of D0-D3 is not
affected. Workaround is to disable breakpoints before the MOV from CR3,TR6
or TR7, execute a jmp right after the move and enabling breakpoints again.
See also <debugging>

On some 386es a MOV to SS may cause a code or data breakpoint set to the
instruction following the MOV to be missed if the instruction takes more
than two clocks. (see <debugging>)

On all 386es a MOV to or from CRx, TRx or DRx executes correctly regardless
of the mod field (the first two bits in the third byte of the opcode).
The mod should be 11b. Intel documentation for the 386 stated it was
undefined.
Some 386 assemblers and compilers may generate values other than 11b for
mod and fail on early 486es, causing an Invalid Opcode Exception, since they
do require the mod field to be correct. More recent 486es recognize the
aliased instructions as valid and execute them accordingly.

On all 386es, moves to or from DR4 and DR5 are aliased to DR6 and DR7.
On the early 486es these encodings are not recognized and generate an
Invalid Opcode Exception. More recent 486es do recognize these aliases and
execute them correctly.

On the A to C0 steps of the 486, loading TR5 with a reg32 operand may hang
the CPU if bits 0 and 1 (control bits) activate cache read, cache write or
flush. A workaround is:

JMP fetcher

ALIGN 16