37

When an x86 CPU is running in real mode, can it be considered to be basically an 8086 CPU (or maybe 8088)? Or are there differences between the two?

Improve this question

2 Answers 2

Reset to default
61

An x86 CPU running in real mode is intended to be backwards-compatible with an 8086 or 8088, but there do end up being a number of differences, for example:

  • newer CPUs run faster (in general);
  • newer CPUs add new instructions (and, with the 386, new registers, since the 32-bit registers can be used in real mode);
  • 286 and later CPUs add more address lines, and the wrapping behaviour of the 8086 meant that IBM had to add the infamous A20 gate to preserve backward-compatibility;
  • instruction timing — the speed of individual CPU instructions — varies from one family to another; some instructions run more slowly on newer CPUs;
  • implementation details vary, and in some cases, can affect run-time behaviour — for example, varying prefetch queue lengths mean that self-modifying code may not work on CPUs other than the model it was written for;
  • some instructions behave differently — for example, PUSH SP on an 8086 decrements SP before pushing it, whereas on a 286 it decrements SP after pushing it, so the value on the stack is different;
  • bus interactions (LOCK prefixes) behave differently on the 8086/8088 compared to all later CPUs;
  • illegal opcodes which run without error on the 8086 produce exceptions on later CPUs;
  • the 8086 has no instruction length limit, whereas instructions which are too long will produce exceptions on later CPUs;
  • segment wraparounds inside an instruction or word access work on the 8086 but trap on later CPUs;
  • stack wraparounds work on the 8086 but will shut down a 286 or later;
  • divide errors behave differently on the 8086/8088 compared to all later CPUs.

The 8086 also has a few bugs which were fixed in later CPUs, but that generally doesn’t matter — all it means is that the workarounds which were needed on 8086/8088 are no longer necessary on later CPUs. (One example is the handling of interrupted instructions with multiple prefixes.)

Software which is actually affected by differences other than speed is very rare indeed, and you can count on the vast majority of software still technically working on a modern x86 CPU in real mode. Speed is another matter; famously, programs written using Turbo Pascal fail with an “Error 200” on CPUs faster than a 200MHz Pentium, and many games don’t cope well with faster CPUs (but some CPUs can be slowed down in creative ways).

Improve this answer
8
  • 3
    Great write up, except speed issues are not really due a changed/extended ISA - they would occure as well back then when speed up occured - after all, having a 10 MHz 8086 was already in the early 1980s a way to screw programs made for a 4.77 MHz 8088
    – Raffzahn
    Apr 5, 2019 at 21:13
  • 3
    Another difference between the 8086 and chips with protected mode: the 286+ didn't wrap around addresses at the 1MB mark in real mode, so IBM had to add an A20 line mask to work around that issue: although not generally an issue on PCs, it could theoretically happen if the A20 line has been enabled to access the UMB region and a program tried using wraparound to access low memory. It's pretty unlikely however: I've never seen a program crash in that manner!
    – ErikF
    Apr 5, 2019 at 23:00
  • 4
    @ErikF: ugh, A20 is an issue on modern PCs for everything except running legacy code, if you boot in legacy BIOS mode. But even that whole way of booting is obsoleted by UEFI, but that doesn't stop the majority of Stack Overflow "osdev" / "bootloader" questions being about legacy BIOS boot sectors. (Which start in real mode with A20 disabled, so it has to be manually enabled if you want to use odd 1MB regions of memory.) Of course, Intel themselves continue to support the undocumented 8086 SALC instruction in 32-bit mode... agner.org/optimize/blog/read.php?i=25
    – Peter Cordes
    Apr 6, 2019 at 3:29
  • 2
    No instruction length limit? Does this mean that F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 81 80 27 09 21 01 will work as normal F0 81 80 27 09 21 01 (i.e. lock add word [bx+si+2343],289)?
    – Ruslan
    Apr 8, 2019 at 7:24
  • 6
    @Ruslan yes, you can produce arbitrary-length instructions using redundant prefixes, and the 8086 won’t complain (up to 64 KiB, IIRC). 286s throw an exception if an instruction is longer than 10 bytes, 386+ if it’s longer than 15 bytes.
    – Stephen Kitt
    Apr 8, 2019 at 7:36
8

When an x86 CPU is running in real mode, can it be considered to be basically an 8086 CPU (or maybe 8088)?

As so often it depends on your value of 'basically' (and there is no user visible difference between 8086 and 8088 beside speed).

Or are there differences between the two?

Well, it's so far the same, as every (modern) x86 operating in real mode will execute pure 8086 programs (*1) adhering to what were legal (*2) instructions (*3) on the 8086.

At the same time they are able to execute later extensions as well while in real mode. So it is possible to write 32-bit real mode programs, or use additional registers and instructions in real mode.

So a x86 isn't the same but for most parts (and depending on the CPU used) a compatible superset of an 8086.

*1 - Lets ignore 'external' hardware differences for this.

*2 - There are a few instructions that changed over time, including basic 8086 ones. They may cause incompatibilities in rare circumstances.

*3 - There are some non-instruction combinations (i.e. prefixes) that were ignored on 8086 but will throw interrupts on later CPUs or result in addressing errors. This is a classic case of later restrictions on less well defined behaviour (like double segment prefix and the like).

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .