Can an x86 CPU running in real mode be considered to be basically an 8086 CPU? The 2019 Stack Overflow Developer Survey Results Are InThe start of x86: Intel 8080 vs Intel 8086?How do you put a 286 in Protected Mode?How do accelerators and CPU cards work on the Apple II?How to use the “darker” CGA palette using x86 Assembly?Examples of operating systems using hardware task switching of x86 CPUsDid the 286 go out of its way to follow the 8088 bus protocol?How did people program for Consoles with multiple CPUs?

How do I free up internal storage if I don't have any apps downloaded?

$EDITOR environment variable won't set

Is bread bad for ducks?

Is it okay to consider publishing in my first year of PhD?

Straighten subgroup lattice

Why isn't the circumferential light around the M87 black hole's event horizon symmetric?

I am an eight letter word. What am I?

Worn-tile Scrabble

Can an undergraduate be advised by a professor who is very far away?

A word that means fill it to the required quantity

Cooking pasta in a water boiler

What could be the right powersource for 15 seconds lifespan disposable giant chainsaw?

What do hard-Brexiteers want with respect to the Irish border?

Deal with toxic manager when you can't quit

Can we generate random numbers using irrational numbers like π and e?

If a sorcerer casts the Banishment spell on a PC while in Avernus, does the PC return to their home plane?

Can withdrawing asylum be illegal?

Geography at the pixel level

Match Roman Numerals

Why does the nucleus not repel itself?

How to notate time signature switching consistently every measure

What is this sharp, curved notch on my knife for?

Why didn't the Event Horizon Telescope team mention Sagittarius A*?

Did Scotland spend $250,000 for the slogan "Welcome to Scotland"?



Can an x86 CPU running in real mode be considered to be basically an 8086 CPU?



The 2019 Stack Overflow Developer Survey Results Are InThe start of x86: Intel 8080 vs Intel 8086?How do you put a 286 in Protected Mode?How do accelerators and CPU cards work on the Apple II?How to use the “darker” CGA palette using x86 Assembly?Examples of operating systems using hardware task switching of x86 CPUsDid the 286 go out of its way to follow the 8088 bus protocol?How did people program for Consoles with multiple CPUs?










32















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?










share|improve this question









New contributor




user12245 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
























    32















    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?










    share|improve this question









    New contributor




    user12245 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.






















      32












      32








      32


      5






      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?










      share|improve this question









      New contributor




      user12245 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.












      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?







      cpu x86






      share|improve this question









      New contributor




      user12245 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      share|improve this question









      New contributor




      user12245 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      share|improve this question




      share|improve this question








      edited Apr 5 at 21:26









      Stephen Kitt

      39.9k8162173




      39.9k8162173






      New contributor




      user12245 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      asked Apr 5 at 20:45









      user12245user12245

      16123




      16123




      New contributor




      user12245 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      user12245 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      user12245 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.




















          2 Answers
          2






          active

          oldest

          votes


















          57














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






          share|improve this answer

























          • 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 at 21:13











          • The fact that it applies to 8MHz v. 4.77 MHz 8086s doesn’t mean it stops applying when comparing any other CPU to an 8086/8088 ;-).

            – Stephen Kitt
            Apr 5 at 21:15






          • 2





            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 at 23:00






          • 3





            @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 at 3:29






          • 1





            Thanks @ErikF, that was indeed an issue (minor nitpick: accessing UMBs didn’t require A20 control, only the HMA did). Significant effort went into correctly handling the A20 line in memory managers...

            – Stephen Kitt
            Apr 6 at 17:05


















          7















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






          share|improve this answer

























            Your Answer








            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "648"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader:
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            ,
            noCode: true, onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );






            user12245 is a new contributor. Be nice, and check out our Code of Conduct.









            draft saved

            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9588%2fcan-an-x86-cpu-running-in-real-mode-be-considered-to-be-basically-an-8086-cpu%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            57














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






            share|improve this answer

























            • 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 at 21:13











            • The fact that it applies to 8MHz v. 4.77 MHz 8086s doesn’t mean it stops applying when comparing any other CPU to an 8086/8088 ;-).

              – Stephen Kitt
              Apr 5 at 21:15






            • 2





              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 at 23:00






            • 3





              @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 at 3:29






            • 1





              Thanks @ErikF, that was indeed an issue (minor nitpick: accessing UMBs didn’t require A20 control, only the HMA did). Significant effort went into correctly handling the A20 line in memory managers...

              – Stephen Kitt
              Apr 6 at 17:05















            57














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






            share|improve this answer

























            • 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 at 21:13











            • The fact that it applies to 8MHz v. 4.77 MHz 8086s doesn’t mean it stops applying when comparing any other CPU to an 8086/8088 ;-).

              – Stephen Kitt
              Apr 5 at 21:15






            • 2





              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 at 23:00






            • 3





              @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 at 3:29






            • 1





              Thanks @ErikF, that was indeed an issue (minor nitpick: accessing UMBs didn’t require A20 control, only the HMA did). Significant effort went into correctly handling the A20 line in memory managers...

              – Stephen Kitt
              Apr 6 at 17:05













            57












            57








            57







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






            share|improve this answer















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







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Apr 8 at 9:41









            Community

            1




            1










            answered Apr 5 at 21:01









            Stephen KittStephen Kitt

            39.9k8162173




            39.9k8162173












            • 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 at 21:13











            • The fact that it applies to 8MHz v. 4.77 MHz 8086s doesn’t mean it stops applying when comparing any other CPU to an 8086/8088 ;-).

              – Stephen Kitt
              Apr 5 at 21:15






            • 2





              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 at 23:00






            • 3





              @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 at 3:29






            • 1





              Thanks @ErikF, that was indeed an issue (minor nitpick: accessing UMBs didn’t require A20 control, only the HMA did). Significant effort went into correctly handling the A20 line in memory managers...

              – Stephen Kitt
              Apr 6 at 17:05

















            • 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 at 21:13











            • The fact that it applies to 8MHz v. 4.77 MHz 8086s doesn’t mean it stops applying when comparing any other CPU to an 8086/8088 ;-).

              – Stephen Kitt
              Apr 5 at 21:15






            • 2





              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 at 23:00






            • 3





              @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 at 3:29






            • 1





              Thanks @ErikF, that was indeed an issue (minor nitpick: accessing UMBs didn’t require A20 control, only the HMA did). Significant effort went into correctly handling the A20 line in memory managers...

              – Stephen Kitt
              Apr 6 at 17:05
















            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 at 21:13





            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 at 21:13













            The fact that it applies to 8MHz v. 4.77 MHz 8086s doesn’t mean it stops applying when comparing any other CPU to an 8086/8088 ;-).

            – Stephen Kitt
            Apr 5 at 21:15





            The fact that it applies to 8MHz v. 4.77 MHz 8086s doesn’t mean it stops applying when comparing any other CPU to an 8086/8088 ;-).

            – Stephen Kitt
            Apr 5 at 21:15




            2




            2





            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 at 23:00





            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 at 23:00




            3




            3





            @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 at 3:29





            @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 at 3:29




            1




            1





            Thanks @ErikF, that was indeed an issue (minor nitpick: accessing UMBs didn’t require A20 control, only the HMA did). Significant effort went into correctly handling the A20 line in memory managers...

            – Stephen Kitt
            Apr 6 at 17:05





            Thanks @ErikF, that was indeed an issue (minor nitpick: accessing UMBs didn’t require A20 control, only the HMA did). Significant effort went into correctly handling the A20 line in memory managers...

            – Stephen Kitt
            Apr 6 at 17:05











            7















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






            share|improve this answer





























              7















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






              share|improve this answer



























                7












                7








                7








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






                share|improve this answer
















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







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Apr 5 at 23:11

























                answered Apr 5 at 21:02









                RaffzahnRaffzahn

                55.8k6136225




                55.8k6136225




















                    user12245 is a new contributor. Be nice, and check out our Code of Conduct.









                    draft saved

                    draft discarded


















                    user12245 is a new contributor. Be nice, and check out our Code of Conduct.












                    user12245 is a new contributor. Be nice, and check out our Code of Conduct.











                    user12245 is a new contributor. Be nice, and check out our Code of Conduct.














                    Thanks for contributing an answer to Retrocomputing Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid


                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.

                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f9588%2fcan-an-x86-cpu-running-in-real-mode-be-considered-to-be-basically-an-8086-cpu%23new-answer', 'question_page');

                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    រឿង រ៉ូមេអូ និង ហ្ស៊ុយលីយេ សង្ខេបរឿង តួអង្គ បញ្ជីណែនាំ

                    Crop image to path created in TikZ? Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)Crop an inserted image?TikZ pictures does not appear in posterImage behind and beyond crop marks?Tikz picture as large as possible on A4 PageTransparency vs image compression dilemmaHow to crop background from image automatically?Image does not cropTikzexternal capturing crop marks when externalizing pgfplots?How to include image path that contains a dollar signCrop image with left size given

                    Romeo and Juliet ContentsCharactersSynopsisSourcesDate and textThemes and motifsCriticism and interpretationLegacyScene by sceneSee alsoNotes and referencesSourcesExternal linksNavigation menu"Consumer Price Index (estimate) 1800–"10.2307/28710160037-3222287101610.1093/res/II.5.31910.2307/45967845967810.2307/2869925286992510.1525/jams.1982.35.3.03a00050"Dada Masilo: South African dancer who breaks the rules"10.1093/res/os-XV.57.1610.2307/28680942868094"Sweet Sorrow: Mann-Korman's Romeo and Juliet Closes Sept. 5 at MN's Ordway"the original10.2307/45957745957710.1017/CCOL0521570476.009"Ram Leela box office collections hit massive Rs 100 crore, pulverises prediction"Archived"Broadway Revival of Romeo and Juliet, Starring Orlando Bloom and Condola Rashad, Will Close Dec. 8"Archived10.1075/jhp.7.1.04hon"Wherefore art thou, Romeo? To make us laugh at Navy Pier"the original10.1093/gmo/9781561592630.article.O006772"Ram-leela Review Roundup: Critics Hail Film as Best Adaptation of Romeo and Juliet"Archived10.2307/31946310047-77293194631"Romeo and Juliet get Twitter treatment""Juliet's Nurse by Lois Leveen""Romeo and Juliet: Orlando Bloom's Broadway Debut Released in Theaters for Valentine's Day"Archived"Romeo and Juliet Has No Balcony"10.1093/gmo/9781561592630.article.O00778110.2307/2867423286742310.1076/enst.82.2.115.959510.1080/00138380601042675"A plague o' both your houses: error in GCSE exam paper forces apology""Juliet of the Five O'Clock Shadow, and Other Wonders"10.2307/33912430027-4321339124310.2307/28487440038-7134284874410.2307/29123140149-661129123144728341M"Weekender Guide: Shakespeare on The Drive""balcony"UK public library membership"romeo"UK public library membership10.1017/CCOL9780521844291"Post-Zionist Critique on Israel and the Palestinians Part III: Popular Culture"10.2307/25379071533-86140377-919X2537907"Capulets and Montagues: UK exam board admit mixing names up in Romeo and Juliet paper"Istoria Novellamente Ritrovata di Due Nobili Amanti2027/mdp.390150822329610820-750X"GCSE exam error: Board accidentally rewrites Shakespeare"10.2307/29176390149-66112917639"Exam board apologises after error in English GCSE paper which confused characters in Shakespeare's Romeo and Juliet""From Mariotto and Ganozza to Romeo and Guilietta: Metamorphoses of a Renaissance Tale"10.2307/37323537323510.2307/2867455286745510.2307/28678912867891"10 Questions for Taylor Swift"10.2307/28680922868092"Haymarket Theatre""The Zeffirelli Way: Revealing Talk by Florentine Director""Michael Smuin: 1938-2007 / Prolific dance director had showy career"The Life and Art of Edwin BoothRomeo and JulietRomeo and JulietRomeo and JulietRomeo and JulietEasy Read Romeo and JulietRomeo and Julieteeecb12003684p(data)4099369-3n8211610759dbe00d-a9e2-41a3-b2c1-977dd692899302814385X313670221313670221