The 80286 introduced something into the x86 architecture called protected mode. Protected mode differed from the original mode of the 8086, which was later dubbed “real mode”, in that areas of memory could be physically isolated by the processor itself to prevent illegal writes to other programs running in memory at the same time. Prior to protected mode, multiple programs could be running in memory at the same time, but any program could access any area of memory and, therefore, if malicious or errant, for example, could take down the entire system.
The 80286 introduced the protected mode to isolate that possibility by allowing the operating system (OS) to dictate where each program should run. While the 80286’s design extended the original 8086’s memory from 1 MB to 24 MB through the addition of new bits for each memory control block (called a “segment selector”), it was still a 16-bit processor. To describe the full ramifications of protected mode programming I am now going to move to the next generation of that design, which is the 80386 and its 32-bit abilities.
The 80386 has been the baseline for every processor developed in x86 space since 1985 when it was originally introduced. Even today’s 64-bit processors are mere extensions of that original design, which is still included completely within the modern 64-bit processors.
Real mode programming involved manipulating data between 0 and 1 MB (minus 1) bytes (in hexadecimal, that is 0×00000 through 0xfffff). The memory there was accessible by any program running in memory. And while, generally speaking, there weren’t multiple programs running in memory at the same time, the OS had to setup things called “interrupt handlers” because the x86 architecture is interrupt driven.
Interrupt driven architectures mean that programs run in sequential order, but are occasionally interrupted to handle external requests. Suppose the user presses a key, how does the computer recognize what they pressed? An external device in the chipset, called an APIC (Advanced, Programmable, Interrupt Controller) signals the processor that there is an external interrupt pending. The processor then, at the completion of the currently executing instruction, branches to the appropriate interrupt handler. The interrupt handler for a keyboard keystroke would involve reading the physical key code from the keyboard, and then running it through some logic to determine what type of keyboard is in use, and what symbol is associated with that keystroke. Also there are considerations like “is CAPS LOCK on?”, or “was the SHIFT KEY also pressed?”, as well as the CTRL key and ALT key.
There are many more interrupts which can occur externally also. Many older PC users will remember these as IRQ conflicts. An IRQ is an “interrupt request”, and every unique thing that requests an interrupt must have its own IRQ so the appropriate handler can be signaled. You wouldn’t want the timer interrupt to be processed by the keyboard handler, or vice-vera. It wouldn’t work and would make the system unusable.
In truth, no single-core processor can multi-task. More accurately, every single-core processor can only do one thing at one time. The thing is it switches between tasks so fast that it appears as though all programs are running at the same time. This can be envisioned by someone cleaning their house. Suppose there’s a mess in the kitchen, the living room and the bedroom. Remember that microprocessors run extremely fast. So fast that even the original 8086 would execute 4.77 million things per second. Today’s processor run a couple billion per second per core. So, envision this: The person A notes the condition of the house at 8am and goes out to the garage to work. The person B is cleaning the house. He works on the kitchen for a bit, the living room for a bit, the bedroom for a bit, and when the person A comes back in all three areas are cleaned. It appears as though B’s cleaned all three at the same time, but in fact he could only do a little bit here and there on each of them.
With microprocessors, the time allocated for each process can be weighted. Suppose there is a very small task that does something minute, or even one that is intelligent enough to recognize that “right now I’m waiting for user input”. Such a task would be able to signal back to the OS that “I’m done for now, go ahead and use the remaining processor clock cycles for some other tasks, if there are any”. The OS recognizes this signal and acts appropriately. If there’s nothing else to do, then on the x86 an instruction called HLT (halt) can be executed. This instruction stops processing until an external interrupt is signaled via the APIC.
I mention all of this to indicate that while multi-tasking in a REAL mode version (the original 8086) is truly possible, it’s not really doing that on the inside. And, due to the fact that every REAL mode program can access all areas of memory without any hardware-based protection mechanism being employed, an errant or malicious program could crash the entire system (which happened regularly).
In protected mode programming, it’s still possible to setup programs which have memory segments which overlap, but it’s rarely profitable to do so. As such, if an errant or malicious program attempts to do something it shouldn’t by accessing memory outside of the OS-assigned boundaries, then it will simply trigger a software interrupt (or internal CPU-generated interrupt) which will be serviced immediately, even before the current instruction is completed (because the current instruction was the one attempting to do the illegal thing), and an appropriate error handler is called via the interrupt service mechanisms.
The most common of these is interrupt 13h, which is “General Protection Fault”. There are several other faults that can be triggered, such as “division by zero”, etc. Each of these conditions rely upon the OS to determine the best course of action. The OS could decide the program has gone haywire and needs to be shut down. Windows, for example, will display the message “Whatever.exe has stopped responding” and then give you options to shut it down or send information about the process to Microsoft. The OS may also be able to correct the problem.
It might be interesting to know that on modern protected mode systems, the OS is constantly handling errors which result. These errors aren’t errors in the programming, but are hardware-allowed conditions which are, most often, related to the paging file. The hardware designers recognized early on that memory is expensive, and while the 80386 could address 4GB, even today some 23 years after the 80386 was introduced, it’s still a high-end option to have 4GB of memory (2GB is more typical). To accommodate the limited memory (original 80386 machines might have had 2MB of memory, then later 4MB, 8MB, 16MB, 32MB and 64MB, pretty much in that order as a progression over time. A Pentium-based machine I bought in 1996 came with 64MB as standard.
The 80386’s protected mode architecture introduces an “absent” bit in memory control blocks related to paging. When a program attempts to run a program or access data in an area of memory which has been swapped out to the paging file, the processor interrupts the program, task switches to the OS’s “page not present” handler, waits for the OS to do whatever it needs to do to restore the memory, and then it will proceed. This is the reason why you see the hard disk going like mad when you’re doing large data moves, or if you use your machine after a long time of not using something. The OS is constantly “optimizing itself” so that its footprint in RAM is as low as possible. This has the side-effect of causing your machine to run much slower than it really is (or should) because the slowest part of the equation at that point is the very slow hard drive speed.
Conclusion
The protected mode architecture introduces many safeguarding features which truly isolate one are of memory from other running programs. Any attempt by another program to access an area of memory the OS has not explicitly allocated to it signals an error or fault, which the OS intercepts and then handles.
This differs from real mode programming where any program can access any area of memory.
It should be noted that on today’s 80386 and later systems, the exact same real mode can be access within a 32-bit framework instead of the original 16-bit framework. This has been dubbed “UNREAL MODE” by hackers. It’s a side-effect of the lazy processing of selectors which takes place inside of a CPU after returning to real mode from protected mode.
It should also be noted that the 80386’s protected mode design allows for a true 32-bit machine to run in the protected mode version of unreal mode. Such a configuration is rare, typically found in custom Linux installs and the like, but has many advantages over traditional OS designs. In fact, the CPUs manufactured today are capable of so much more speed than we (the users) are seeing with operating systems like Linux and Windows. Paging alone introduces a huge slowdown which I have personally witnessed to be nearly 2x that of a non-paged system.
The advantages are there in hardware. Protected mode introduced real, true, usable abilities over real mode. Today’s software depends upon it. There are also all kinds of errata over the years related to boundary errors, and failure to recognize when errors should be triggered, etc. These are usually non-issue errors, but can be in certain circumstances. In addition, if it weren’t for protected mode, the concept of anti-virus and malware detection would be far more difficult.
The 80386 and later processor also contain additional operational modes, including SMM (System Management Mode) which operates when the machine is in “sleep mode”, and other modes.
