Can an x86 CPU running in real mode be considered to be basically an 8086 CPU?The 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?

Replacing matching entries in one column of a file by another column from a different file

What are these boxed doors outside store fronts in New York?

A case of the sniffles

Did Shadowfax go to Valinor?

Are astronomers waiting to see something in an image from a gravitational lens that they've already seen in an adjacent image?

Convert two switches to a dual stack, and add outlet - possible here?

Why is consensus so controversial in Britain?

Malformed Address '10.10.21.08/24', must be X.X.X.X/NN or

RSA: Danger of using p to create q

Horror movie about a virus at the prom; beginning and end are stylized as a cartoon

Can I ask the recruiters in my resume to put the reason why I am rejected?

Maximum likelihood parameters deviate from posterior distributions

Could an aircraft fly or hover using only jets of compressed air?

NMaximize is not converging to a solution

How old can references or sources in a thesis be?

Why doesn't H₄O²⁺ exist?

Unable to deploy metadata from Partner Developer scratch org because of extra fields

Theorems that impeded progress

How much of data wrangling is a data scientist's job?

Approximately how much travel time was saved by the opening of the Suez Canal in 1869?

Was any UN Security Council vote triple-vetoed?

Cross compiling for RPi - error while loading shared libraries

"You are your self first supporter", a more proper way to say it

What's that red-plus icon near a text?



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


The 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?













2















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.
























    2















    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.






















      2












      2








      2








      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 4 hours ago









      Stephen Kitt

      39.3k8160173




      39.3k8160173






      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 5 hours ago









      user12245user12245

      111




      111




      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


















          10














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

          • 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 increments SP after pushing it, whereas on a 286 it increments SP before 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
            5 hours ago











          • 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
            5 hours ago











          • True, and I don't want to put this down, as it (may) be the most obvious (and usually intended) effect. Just, as far as I understand the intention of the question is about any difference originated in a changed/extended ISA, not a higher clock frequency - after all, we always can clock down faster CUs (at least I hope so :))

            – Raffzahn
            5 hours ago











          • 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
            3 hours ago


















          1















          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




















          • 1





            As usual, receiving a down vote is cool - but without any reasoning its rather senseless if not cowardly, isn't it? So, what part made you hitting the button?

            – Raffzahn
            5 hours ago







          • 1





            Have an upvote to balance things out ;-).

            – Stephen Kitt
            4 hours ago











          • @StephenKitt Thanks. Cool. (BTW, your answer is the better, more detailed anyway (sans the speed issue that is :))) Still I'd like to know what people consider worth a downvote. I assume it's well know that I don't doge any confrontation. To me there's nothing more helpful in finding a good answer than people applying critical thinking on what has been said. So I'm genuinely interested in what seams to be downvoteworthy.

            – Raffzahn
            3 hours ago












          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









          10














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

          • 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 increments SP after pushing it, whereas on a 286 it increments SP before 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
            5 hours ago











          • 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
            5 hours ago











          • True, and I don't want to put this down, as it (may) be the most obvious (and usually intended) effect. Just, as far as I understand the intention of the question is about any difference originated in a changed/extended ISA, not a higher clock frequency - after all, we always can clock down faster CUs (at least I hope so :))

            – Raffzahn
            5 hours ago











          • 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
            3 hours ago















          10














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

          • 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 increments SP after pushing it, whereas on a 286 it increments SP before 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
            5 hours ago











          • 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
            5 hours ago











          • True, and I don't want to put this down, as it (may) be the most obvious (and usually intended) effect. Just, as far as I understand the intention of the question is about any difference originated in a changed/extended ISA, not a higher clock frequency - after all, we always can clock down faster CUs (at least I hope so :))

            – Raffzahn
            5 hours ago











          • 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
            3 hours ago













          10












          10








          10







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

          • 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 increments SP after pushing it, whereas on a 286 it increments SP before 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);

          • 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 increments SP after pushing it, whereas on a 286 it increments SP before 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 5 hours ago

























          answered 5 hours ago









          Stephen KittStephen Kitt

          39.3k8160173




          39.3k8160173












          • 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
            5 hours ago











          • 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
            5 hours ago











          • True, and I don't want to put this down, as it (may) be the most obvious (and usually intended) effect. Just, as far as I understand the intention of the question is about any difference originated in a changed/extended ISA, not a higher clock frequency - after all, we always can clock down faster CUs (at least I hope so :))

            – Raffzahn
            5 hours ago











          • 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
            3 hours ago

















          • 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
            5 hours ago











          • 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
            5 hours ago











          • True, and I don't want to put this down, as it (may) be the most obvious (and usually intended) effect. Just, as far as I understand the intention of the question is about any difference originated in a changed/extended ISA, not a higher clock frequency - after all, we always can clock down faster CUs (at least I hope so :))

            – Raffzahn
            5 hours ago











          • 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
            3 hours ago
















          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
          5 hours ago





          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
          5 hours ago













          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
          5 hours ago





          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
          5 hours ago













          True, and I don't want to put this down, as it (may) be the most obvious (and usually intended) effect. Just, as far as I understand the intention of the question is about any difference originated in a changed/extended ISA, not a higher clock frequency - after all, we always can clock down faster CUs (at least I hope so :))

          – Raffzahn
          5 hours ago





          True, and I don't want to put this down, as it (may) be the most obvious (and usually intended) effect. Just, as far as I understand the intention of the question is about any difference originated in a changed/extended ISA, not a higher clock frequency - after all, we always can clock down faster CUs (at least I hope so :))

          – Raffzahn
          5 hours ago













          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
          3 hours ago





          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
          3 hours ago











          1















          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




















          • 1





            As usual, receiving a down vote is cool - but without any reasoning its rather senseless if not cowardly, isn't it? So, what part made you hitting the button?

            – Raffzahn
            5 hours ago







          • 1





            Have an upvote to balance things out ;-).

            – Stephen Kitt
            4 hours ago











          • @StephenKitt Thanks. Cool. (BTW, your answer is the better, more detailed anyway (sans the speed issue that is :))) Still I'd like to know what people consider worth a downvote. I assume it's well know that I don't doge any confrontation. To me there's nothing more helpful in finding a good answer than people applying critical thinking on what has been said. So I'm genuinely interested in what seams to be downvoteworthy.

            – Raffzahn
            3 hours ago
















          1















          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




















          • 1





            As usual, receiving a down vote is cool - but without any reasoning its rather senseless if not cowardly, isn't it? So, what part made you hitting the button?

            – Raffzahn
            5 hours ago







          • 1





            Have an upvote to balance things out ;-).

            – Stephen Kitt
            4 hours ago











          • @StephenKitt Thanks. Cool. (BTW, your answer is the better, more detailed anyway (sans the speed issue that is :))) Still I'd like to know what people consider worth a downvote. I assume it's well know that I don't doge any confrontation. To me there's nothing more helpful in finding a good answer than people applying critical thinking on what has been said. So I'm genuinely interested in what seams to be downvoteworthy.

            – Raffzahn
            3 hours ago














          1












          1








          1








          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 3 hours ago

























          answered 5 hours ago









          RaffzahnRaffzahn

          55.3k6136224




          55.3k6136224







          • 1





            As usual, receiving a down vote is cool - but without any reasoning its rather senseless if not cowardly, isn't it? So, what part made you hitting the button?

            – Raffzahn
            5 hours ago







          • 1





            Have an upvote to balance things out ;-).

            – Stephen Kitt
            4 hours ago











          • @StephenKitt Thanks. Cool. (BTW, your answer is the better, more detailed anyway (sans the speed issue that is :))) Still I'd like to know what people consider worth a downvote. I assume it's well know that I don't doge any confrontation. To me there's nothing more helpful in finding a good answer than people applying critical thinking on what has been said. So I'm genuinely interested in what seams to be downvoteworthy.

            – Raffzahn
            3 hours ago













          • 1





            As usual, receiving a down vote is cool - but without any reasoning its rather senseless if not cowardly, isn't it? So, what part made you hitting the button?

            – Raffzahn
            5 hours ago







          • 1





            Have an upvote to balance things out ;-).

            – Stephen Kitt
            4 hours ago











          • @StephenKitt Thanks. Cool. (BTW, your answer is the better, more detailed anyway (sans the speed issue that is :))) Still I'd like to know what people consider worth a downvote. I assume it's well know that I don't doge any confrontation. To me there's nothing more helpful in finding a good answer than people applying critical thinking on what has been said. So I'm genuinely interested in what seams to be downvoteworthy.

            – Raffzahn
            3 hours ago








          1




          1





          As usual, receiving a down vote is cool - but without any reasoning its rather senseless if not cowardly, isn't it? So, what part made you hitting the button?

          – Raffzahn
          5 hours ago






          As usual, receiving a down vote is cool - but without any reasoning its rather senseless if not cowardly, isn't it? So, what part made you hitting the button?

          – Raffzahn
          5 hours ago





          1




          1





          Have an upvote to balance things out ;-).

          – Stephen Kitt
          4 hours ago





          Have an upvote to balance things out ;-).

          – Stephen Kitt
          4 hours ago













          @StephenKitt Thanks. Cool. (BTW, your answer is the better, more detailed anyway (sans the speed issue that is :))) Still I'd like to know what people consider worth a downvote. I assume it's well know that I don't doge any confrontation. To me there's nothing more helpful in finding a good answer than people applying critical thinking on what has been said. So I'm genuinely interested in what seams to be downvoteworthy.

          – Raffzahn
          3 hours ago






          @StephenKitt Thanks. Cool. (BTW, your answer is the better, more detailed anyway (sans the speed issue that is :))) Still I'd like to know what people consider worth a downvote. I assume it's well know that I don't doge any confrontation. To me there's nothing more helpful in finding a good answer than people applying critical thinking on what has been said. So I'm genuinely interested in what seams to be downvoteworthy.

          – Raffzahn
          3 hours ago











          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

          Disable / Remove link to Product Items in Cart Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?How can I limit products that can be bought / added to cart?Remove item from cartHide “Add to Cart” button if specific products are already in cart“Prettifying” the custom options in cart pageCreate link in cart sidebar to view all added items After limit reachedLink products together in checkout/cartHow to Get product from cart and add it againHide action-edit on cart page if simple productRemoving Cart items - ObserverRemove wishlist items when added to cart

          Helsingin valtaus Sisällysluettelo Taustaa | Yleistä sotatoimista | Osapuolet | Taistelut Helsingin ympäristössä | Punaisten antautumissuunnitelma | Taistelujen kulku Helsingissä | Valtauksen jälkeen | Tappiot | Muistaminen | Kirjallisuutta | Lähteet | Aiheesta muualla | NavigointivalikkoTeoksen verkkoversioTeoksen verkkoversioGoogle BooksSisällissota Helsingissä päättyi tasan 95 vuotta sittenSaksalaisten ylivoima jyräsi punaisen HelsinginSuomalaiset kuvaavat sotien jälkiä kaupungeissa – katso kuvat ja tarinat tutuilta kulmiltaHelsingin valtaus 90 vuotta sittenSaksalaiset valtasivat HelsinginHyökkäys HelsinkiinHelsingin valtaus 12.–13.4. 1918Saksalaiset käyttivät ihmiskilpiä Helsingin valtauksessa 1918Teoksen verkkoversioTeoksen verkkoversioSaksalaiset hyökkäävät Etelä-SuomeenTaistelut LeppävaarassaSotilaat ja taistelutLeppävaara 1918 huhtikuussa. KapinatarinaHelsingin taistelut 1918Saksalaisten voitonparaati HelsingissäHelsingin valtausta juhlittiinSaksalaisten Helsinki vuonna 1918Helsingin taistelussa kaatuneet valkokaartilaisetHelsinkiin haudatut taisteluissa kaatuneet punaiset12.4.1918 Helsingin valtauksessa saksalaiset apujoukot vapauttavat kaupunginVapaussodan muistomerkkejä Helsingissä ja pääkaupunkiseudullaCrescendo / Vuoden 1918 Kansalaissodan uhrien muistomerkkim

          Adjektiivitarina Tarinan tekeminen | Esimerkki: ennen | Esimerkki: jälkeen | Navigointivalikko