Expand down stack segment setting on x86

[rdos]

AFAIK, there are no limit checks in real mode, nor any double fault handler. The only fault that exists (except for single step) is invalid opcode.

Limit checks are definitely enabled in real mode - otherwise there wouldn't been a difference with Unreal mode.

For that very same reason, GPFs work just fine, as do the majority of others: division by zero, debug, breakpoint, bounds failed, math fault etc.

Not in the original real mode. The 8086 processor certainly didn't have base or limit fields for segment registers. This is an after-construction in later processors that simply don't exist in the original real mode. I doubt that GPF was defined in the 8086 processor either, especially since it overlaps with PIC interrupts. And all current processors sets up the segment limits for real mode in a way that makes it impossible to exceed them with instructions available in the original 16-bit mode (IOW, 16-bit instructions).

Math faults also didn't work the same, as the math processor was not integrated into the CPU, but was an optional chip that reported errors with an interrupt.

Things like "unreal mode" where limits are set to 4G are just exploits of quirks in later processors that never worked in the original real mode environment.

[bluemoon]

AFAIK, there are no limit checks in real mode.
<snip>
Not in the original real mode. The 8086 processor ...

Then, you should specify there are no limit checks in real mode on 8086. Your speech induce a confusion that "there are no limit checks in real mode in any case", which is certainly wrong for 386 and other - You know that, we know that, but it may confuse someone who trying to learn it.

[Combuster]

And the 8086 actually did not have the invalid opcode exception, so you're just trying to talk (lie) your way out again instead of admitting you were wrong. Get over it, it's healthy.

[16bitPM]

Not in the original real mode. The 8086 processor certainly didn't have base or limit fields for segment registers. This is an after-construction in later processors that simply don't exist in the original real mode. I doubt that GPF was defined in the 8086 processor either, especially since it overlaps with PIC interrupts. And all current processors sets up the segment limits for real mode in a way that makes it impossible to exceed them with instructions available in the original 16-bit mode (IOW, 16-bit instructions).

Of course, limit checks are from Protected Mode. There was no such thing as "Real Mode" on a 8086/8088, because PM was not invented yet. But the SIMULATION of that CPU is called "Real Mode, and it is surprisingly little different from protected mode. Maybe this page will explain things: Will the real Real Mode please stand up?

[16bitPM]

AFAIK, there are no limit checks in real mode.
<snip>
Not in the original real mode. The 8086 processor ...

Then, you should specify there are no limit checks in real mode on 8086. Your speech induce a confusion that "there are no limit checks in real mode in any case", which is certainly wrong for 386 and other - You know that, we know that, but it may confuse someone who trying to learn it.

I repeat: the 8088 does not even have real mode. It wasn't invented yet. Real mode is a simulation of the 8088 on a CPU with protection features.

[rdos]

As a programmer of 8086-compatible chips (V25 processor), I find this discussion useless. There is no point in using real mode on a 386+ processor, and if you write an OS/application for 8086-compatible chips, you cannot bother with 386-only features of "real mode".

[Combuster]

Well, now it's not only rdos who sadly needs perpetual correcting, but even 16bitpm is joining this troll. Shame on both of you.

There is no point in using real mode on a 386+ processor

Then what's the BIOS doing there? Once again, GTFO.

I repeat: the 8088 does not even have real mode. It wasn't invented yet. Real mode is a simulation of the 8088 on a CPU with protection features.

If it looks like a cat, sounds like a cat, feels like a cat, it is for all intents and purposes a cat. Do you call a 8088 a fake because it emulates an 8086 using a smaller data bus as well? Real mode as the term exists only to differentiate from the new protected mode, as such covers all x86 and x88 chips, and therefore exists on all those. And that's besides the fact that your usage contradicts the de-facto usage of the term and should be avoided since it is in straight contradiction with every else that has been said on this forum and the wiki.

And since you bothered to spoil your own thread with this nonsense, I'm going to ask for a lock.

[rdos]

And the 8086 actually did not have the invalid opcode exception

Check your sources again. The invalid opcode exception has existed ever since 8088.

List of exceptions from 8088 manual:

0 Divide Error Processor - zero or overflow
1 Single Step (DEBUG) Processor - TF=1
2 Nonmaskable Interrupt Pin Processor - NMI Signal
3 Breakpoint Processor - Similar to Sing Step
4 Arithmetic Overflow Processor - into
6 Invalid Opcode Processor - Invalid Opcode
7 Coprocessor Not Present Processor - no FPU

so you're just trying to talk (lie) your way out again instead of admitting you were wrong. Get over it, it's healthy.

What's is interesting is if you would admit to lying about invalid opcode not being supported by 8088.

[Combuster]

List of exceptions from 8088 manual

I got the manual and it wasn't there. This however does exist, and is only one of many references found on the top of google.

[rdos]

Seems you are right about the original Intel chip (see discussion here: http://www.digipedia.pl/usenet/thread/1100/2481/). However, for 8086-compatible chips that are still manufactured (like NEC V25), those are 186-compatible, and thus does have invalid opcode. I think that most clones that can still be bought does have invalid opcode.

[bluemoon]

I find this discussion useless.

Now we have agreed something.

[linguofreak]

There was no such thing as "Real Mode" on a 8086/8088, because PM was not invented yet.[/url]

Technically true, but a useless quibble in practice. Real mode was meant to emulate the 8086 as closely as possible, so it's more useful to say that the 8086 had a single unnamed mode that was named "real mode" after the fact.