OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 4:46 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: 16 bits Real Mode vs 16 bits Protected Mode vs v8086 Mode
PostPosted: Fri Nov 03, 2017 12:32 pm 
Offline
Member
Member
User avatar

Joined: Sat May 20, 2017 1:25 am
Posts: 51
Location: PCI bus: 3, slot: 9, function: 5
what are the differences of these modes? Do there exist other "16 bits" modes? Also what are compatibility mode?

_________________
How people react when a new update of your OS is coming:
Linux user: Cool, more free stuff!
Mac user: Ooh I have to pay!
Windows user: Ah not again!


Top
 Profile  
 
 Post subject: Re: 16 bits Real Mode vs 16 bits Protected Mode vs v8086 Mod
PostPosted: Fri Nov 03, 2017 5:35 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
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

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: 16 bits Real Mode vs 16 bits Protected Mode vs v8086 Mod
PostPosted: Fri Nov 03, 2017 7:54 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
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.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: 16 bits Real Mode vs 16 bits Protected Mode vs v8086 Mod
PostPosted: Sat Nov 04, 2017 3:05 pm 
Offline
Member
Member

Joined: Fri Aug 26, 2016 1:41 pm
Posts: 671
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Majestic-12 [Bot] and 71 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group