VOGONS


First post, by superfury

User metadata
Rank l33t++
Rank
l33t++

I know that on a 186+ it generates an #UD. What happens on a 8086, which doesn't support #UD? Is it simply implemented as a NOP instruction? Or is it actually executed?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 1 of 4, by Jepael

User metadata
Rank Oldbie
Rank
Oldbie
superfury wrote:

I know that on a 186+ it generates an #UD. What happens on a 8086, which doesn't support #UD? Is it simply implemented as a NOP instruction? Or is it actually executed?

Good question, I would try it if I had a 8088/8086. Even if it did change CS, most likely it would not empty the prefetch queue, so it would contain instructions fetched from old cs and new cs (ip is not reset). So if any piece of software would use the mov cs, ax instruction, it would be quite specific environment it works in, regarding bus cycles and DMA cycles, so that the change of CS happens at exactly correct point. That's why opcodes that change CS without emptying prefetch queue have "do not use" explanation in manuals, and later they generate #UD.

Reply 2 of 4, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

Interesting question. My emulator blurts out an assert in assert builds in just goes to next opcode in release builds. But according to http://www.os2museum.com/wp/undocumented-8086-opcodes/ and http://textfiles.com/programming/86bugs.lst we have this:

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 […]
Show full quote

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>.

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 3 of 4, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

Also, this is what PCEM does as well: it actually does load CS. There is a comment in there saying "8088/8086 only" but I do not see that enforced in the code.

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 4 of 4, by peterferrie

User metadata
Rank Oldbie
Rank
Oldbie

Yes, it really loads CS, as you'd expect. It was even used by an early bootsector virus, whose name escapes me at the moment.
The idea is that you copy a block of memory to the desired segment where IP matches exactly, so only the segment value differs, and then mov cs, reg to transfer control there.