HardwareBanter (http://www.hardwarebanter.com/index.php)
-   Homebuilt PC's (http://www.hardwarebanter.com/forumdisplay.php?f=36)
-   -   Protected vs Real (http://www.hardwarebanter.com/showthread.php?t=19785)

esara April 30th 04 08:31 PM

Protected vs Real
I am reading a course about A+. in One slide which has title od
"Real(16-bit) and Protected (32-bit) Operation Mode" (please see
My questions:
1) does the real mode mean DOS and protected me Windows? if yes why
they are named so??
2) Why Real mode can access 1Mb memory while protected can access 4Gb
3) Why the Protected Mode can not do direct access to the memory??

Thanks a lot for the help

Real(16-bit) and Protected (32-bit) Operation Mode
+ Real Mode
- Single task
- 16-bit data path, 1Mb of memory
- Direct Access Memory

+ Protected Mode
- Multitasking
- 32-bit data path; at least 4Gb of memory address
- OS manages access to RAM and does not allow a program direct
acces to it

ancra May 1st 04 06:00 AM

On 30 Apr 2004 12:31:29 -0700, (esara) wrote:

I am reading a course about A+. in One slide which has title od
"Real(16-bit) and Protected (32-bit) Operation Mode" (please see
My questions:
1) does the real mode mean DOS and protected me Windows? if yes why
they are named so??

No. These modes concern the cpus addressing. It's 'hardware' and not
something coming from the OS. The OS' function and rules for the
software model, use these modes. But we can ignore the OS when
speaking about this.

2) Why Real mode can access 1Mb memory while protected can access 4Gb

The '386 class ('386 and all following Intel and AMD cpus, up to, but
not including K8), have 4 modes, or addressing modes (and K8=AMD64
have a few more).
They don't have all these modes for funs sake, or because they are
clever (it's all Intel's fault ;)). They are there because of heritage
and the requirement of backwards compatibility. 'Real mode' is an
addressing scheme from an early cpu, from the days Intel figured 1MB
was enough.

3) Why the Protected Mode can not do direct access to the memory??

This is entirely intentional. And every modern cpu and modern OS
should work this way. The addresses used by the software, doesn't lead
anywhere else than to a mechanism, translating them to other
addresses. They are mapped to real, physical addresses by the OS.
(Even if the cpu does the mapping automatically by itself, the OS sets
it up and controls memory allocation and access).
Any address must be allocated by the OS, and thus also mapped to an
effective address. If an application tries to use any number just out
of the blue, you will see an error message and the application will be

*****REAL MODE*****

The first mode - 'real mode' was the addressing mode of the 8086.

The 8086 ISA have instructions that refer to data in memory with a
16-bit address. 16 bits can only represent 65,536 (64K) numbers, and
are not enough to specify a byte in memory. So the instructions 16
bits (page) are combined with the content in an 16 bit segment
register, to form a 20 bit address (0000 is appended to the end of the
segment and the instruction address is added).

This address goes out directly on the physical addressbus. The
software generating the instruction's 16-bit address must also set the
segment register, and is fully responsible for the outgoing 20-bit
addresses being correct.
(This is a horrible way to build software)

Because the software's own idea of addresses, the softwares memory
model, is exactly the same as the physical memory, - this is called
"real mode".

And because only 20-bit addresses can be formed, in this mode of
addressing, only 1MB can be addressed. 2^20 = 1,048,576 = 1024K = 1M.
Classic DOS, '86 DOS, take this memory environment for granted.


The second mode, 16-bit protected mode, was introduced with the '286.

Again, the ISA use instructions with 16 bit long addresses. Again the
software itself is responsible for setting the segment register.
(Code always only refer to one segment of memory at time, and the
software must switch this segment through the segment register.)

But this time the software sets a 13-bit selector in the old 16-bit
segment register. - And it is _NOT_ combined with the 16-bit address
to form the physical address.

Instead, there are two new 40-bit registers in the cpu, 'global' and
'local' 'descriptor table register'. These are not set by the
application software. The OS sets these, with privileged instructions.

These registers points to a 'descriptor table' in memory (actually,
typically in the L1cache, so now you know what the L1 cache is used
for :).)

The OS can set up one 'local descriptor table' for each application.
When the OS intends to run an application, it first loads the address
of the application's descriptor table into the 'local' register.

The table contains 'page descriptors'. these are 8 byte data structs.
The OS sets up these page descriptors as it allocates memory for the

So the following happens, when an instruction refers to some data with
a 16-bit address: The selector, in the segment register, selects a
page descriptor in the descriptor table that the 'local' register
points to. This page descriptor gives a 24-bit address to the base of
a 64KB segment. It is then used together with the 16-bit address to
form a physical 24-bit address. This is good for addressing 16MB

So the _software_ address _is_, as before, the segment register and
the 16-bit address. But this time, that address is mapped to something
completely different.

Since each application can have it's own mapping (local table), -
this way -, different applications use of memory _can_ be kept
separate and protected from each other. Thus: "protected mode".
(Note: "can". That doesn't mean any OS or dirty-dos-extendender must
necessarily do so, while using this mode.)

This '16-bit protected mode' is what 'Windows16' software and DMPI-DOS


Both "real mode" and "16-bit protected mode" are pretty close to
software HELL, and thus quite uncomfortable.
The '386 introduced a 32-bit ISA, and two new addressing modes.
The most important is the '32-bit protected mode'. This is important
for two reasons: It offers greater memory space. And most important of
all - it can be used to implement a flat, linear software memory

It looks a lot like 16-bit protected mode, but new instructions now
use 32-bit addresses, and the segment register too, is 32 bit wide.

Typically, an application is linear, has a 4GB large 'segment, and the
application _never_ changes its segment register. So the software
model address is in practice only the 32 bits included directly in the
instruction. - How convenient! No segment selection to manage.
Used this way, and Win 9x and NT do, the segment register doesn't come
into play.

As before, that 32-bit virtual address is mapped to an effective
address, with a memory descriptor. But in this case we are using the
first 20 bits of the 32-bit address, as indexes into the descriptor,
to form the 32-bit address of a 4KB *page* (it doesn't overlap) rather
than a segment. The last 12 bytes gives the address into this 4KB

It's possible for the OS to cut off the software completely from
accessing any hardware address. And it can shuffle around and store
those 4K pages anywhere it want, including harddrive.

With the help of a lot of clever complexity, descriptors and table
registers are compatible with 16-bit protected mode, and allows an OS
to run both types of modes, side by side, in a single memory

However, old 'real mode' cannot run together with either protected
mode. In real mode, the software must have direct access to the lowest
MB memory, and also goes out and stomps all over it.


For that reason, the '386 also introduced 'virtual real mode'. This is
a mode that fools an old application into believing that it is running
in real mode. In reality, it runs in protected mode, and that 1MB
*physical* ram is mapped to wherever the OS wants it.
This is how the Windows OSes handle DOS inside windows and
concurrently with other apps. This is a sort of 8086 emulator in
hardware, inside the cpu.


All times are GMT +1. The time now is 02:02 PM.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.