OSDev.org

what are the differences of these modes? Do there exist other "16 bits" modes? Also what are compatibility mode?

Hi,

ARISTOS wrote:what are the differences of these modes?

Most (but not all) of the differences between real mode and protected are how memory accesses work. In general (for all CPU modes); every virtual memory access has an (implicit or explict) segment. The CPU starts by converting the virtual address to a linear address, then converts the linear address into a physical address.

In real mode; to convert a virtual address to a linear address the CPU starts by checking if the offset is within the segment limit (which is always 64 KiB), then does "linear = segment * 16 + offset". To convert the linear address to a physical address it does nothing - it's just "physical = linear". Because segment registers are 16 bit, segment limits are 64 KiB (and offset is 16-bit) and the CPU does nothing to convert linear addresses into physical addresses; real mode can only access slightly more than 1 MiB of the physical address space (e.g. the highest virtual address is 0xFFFF:0xFFFF, which becomes the linear address 0xFFFF*16+0xFFFF=0x0010FFEF which is the physical address 0x0010FFEF too). Because there's very few checks there's no security either (any code can trash anything and there's no way to protect anything from malware, etc).

In protected mode all of a segment's attributes (type, base address, limit, etc) are set from an entry in a table when the segment register is loaded (a table entry describes the segment and is called a "descriptor", and there's two tables - a global descriptor table/GDT and a local descriptor table/LDT). To convert a virtual address to a linear address the CPU starts by doing some sanity checks (if the access is allowed by the segment's type, if the current privilege level is high enough), then checks if the offset is within the segment limit, then does "linear = segment.base + offset". If paging is turned off, to convert the linear address to a physical address the CPU does nothing (same as in real mode). If paging is turned on, TLBs (and page tables, page directories, etc if it wasn't in the TLBs) to convert the linear address to a physical address. It's a bit more complicated; but can be extremely secure (if it's done right) and extremely flexible (which creates the ability to use various "virtual memory management" tricks to reduce RAM usage, improve performance, etc).

In addition to differences in how memory accesses work:

• Protected mode allows you to set the default code size in the descriptor for the code segment to 16-bit or 32-bit (and you aren't stuck with 16-bit). For a 32-bit code size (the most common choice) it means that you don't need size override prefixes on 32-bit instructions (but do need size override prefixes on 16-bit instructions).
• There's some extra protection/security for some special instructions, so that only the most privileged code can use them ("mov cr0, ...", "mov cr3, ...", "rdmsr", etc).
• There's some extra protection/security for some special instructions that used to deal with hardware devices ("in", "out", "hlt", "cli", "sti", etc).
• There's support for hardware task switching
• There's a special sub-mode (called "virtual 8086 mode") to allow legacy code (e.g. MS-DOS applications) with all of the flexibility and security features provided by protected mode

Note that most modern OSs don't use a lot of the features protected mode provides. Specifically, they don't use segmentation (because paging is so flexible there's hardly any reason to bother), they don't use virtual 8086 mode very much (because legacy code is all dead - nobody cares about MS-DOS applications anymore), and nobody uses hardware task switching much (because it's faster and easier to do it task switching yourself in software).

ARISTOS wrote:Do there exist other "16 bits" modes?

For "80486 and later" (including some special 80386 chips that were created for embedded use after 80486 was released) there's one other 16-bit mode, called System Management Mode (SMM). This mode is designed to allow firmware to do things in the background (e.g. power management, some legacy device emulation, handling a few things for ECC) to reduce the cost of hardware (e.g. so that hardware doesn't need extra transistors/circuitry). Because it's only intended for "hardware assist" (and because there's some security implications), SMM can't be used by normal software (including operating systems) and normal software developers (including operating system developers) don't really need to know that SMM exists.

ARISTOS wrote:Also what are compatibility mode?

There is one other mode, called long mode. Long mode is like protected mode; except that paging is a little different (to handle larger 48-bit virtual addresses) and that it supports 64-bit code; and because it doesn't support some features nobody uses anyway (hardware task switching, most of segmentation and "virtual-8086 mode" sub-mode). Within long mode, the manufacturer just assumed everyone would want to use 64-bit code (), so

Long mode supports 16-bit, 32-bit and 64-bit code; but there isn't much point using long mode if you aren't also using 64-bit code. This is what "compatibility mode" is - it's just long mode executing 16-bit or 32-bit code (most likely for compatibility purposes - for older executables originally designed for a protected mode OS).


Ignoring hardware virtualisation, the modes the CPU supports and their "sub-modes" are:

• SMM
• Real mode
• Protected mode
  • 32-bit code in protected mode
  • 16-bit code in protected mode
  • Virtual 8086 mode in protected mode
• Long mode
  • 64-bit code in long mode
  • 32-bit code in long mode ("compatibility mode")
  • 16-bit code in long mode ("compatibility mode")

Cheers,

Brendan

I believe that ARISTOS was asking about 16-bit (286) p-mode specifically, but since the correct answer to questions about that is, "don't bother" (the mode itself is of only historical interest, and has little if any real relevance in trying to understand either real mode or 32-bit p-mode; it can be safely disregarded for any hardware more recent than the 80286 - and I don't think Intel has even produced 286s since around 1992), I would say that the rest of Brendan's post is appropos anyway.

Schol-R-LEA wrote:I don't think Intel has even produced 286s since around 1992)

80286 based processors by other manufacturers are still produced and sold by third parties (albeit more scarce) in the embedded space. Embedded variants of the 80186 are probably more common place though.