X86 memory segmentation: Difference between revisions

Content deleted Content added
AnomieBOT (talk | contribs)
m Dating maintenance tags: {{Fact}}
no sentence
Tags: Visual edit Mobile edit Mobile web edit Advanced mobile edit
 
(5 intermediate revisions by 4 users not shown)
Line 7:
In 1982, the [[Intel 80286]] added support for [[virtual memory]] and [[memory protection]]; the original mode was renamed '''[[real mode]]''', and the new version was named '''[[protected mode]]'''. The [[x86-64]] architecture, introduced in 2003, has largely dropped support for segmentation in 64-bit mode.
 
In both real and protected modes, the system uses 16-bit ''segment registers'' to derive the actual memory address. {{anchor|Extra segment}}In real mode, the registers CS, DS, SS, and ES point to the currently used program [[code segment]] (CS), the current [[data segment]] (DS), the current [[stack segment]] (SS), and one ''extra'' segment determined by the system programmer (ES). The [[Intel 80386]], introduced in 1985, adds two additional segment registers, FS and GS, with no specific uses defined by the hardware. The way in which the segment registers are used differs between the two modes.<ref name=Arch />
 
The choice of segment is normally defaulted by the processor according to the function being executed. Instructions are always fetched from the code segment. Any data reference to the stack, including any stack push or pop, uses the stack segment; data references indirected through the BP register typically refer to the stack and so they default to the stack segment. The extra segment is the mandatory destination for string operations (for example MOVS or CMPS); for this one purpose only, the automatically selected segment register cannot be overridden. All other references to data use the data segment by default. The data segment is the default source for string operations, but it can be overridden. FS and GS have no hardware-assigned uses. The instruction format allows an optional ''segment prefix'' byte which can be used to override the default segment for selected instructions if desired.<ref>{{cite book|last=Intel Corporation|title=IA-32 Intel Architecture Software Developer's Manual Volume 1: Basic Architecture|date=2004|url=http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-1-manual.pdf}}</ref>
Line 56:
{{refimprove section|date=August 2015}}
 
[[Image:Protected mode segments.svg|thumb|300px|left|Three segments in [[protected mode]] memory (click on image to enlarge), with the '''local descriptor table'''.]]
 
=== 80286 protected mode ===
Line 63:
286 protected mode was seldom used as it would have excluded the large body of users with 8086/88 machines. Moreover, it still necessitated dividing memory into 64k segments like was done in real mode. This limitation can be worked around on 32-bit CPUs which permit the use of memory pointers greater than 64k in size, however as the Segment Limit field is only 24-bit long, the maximum segment size that can be created is 16MB (although paging can be used to allocate more memory, no individual segment may exceed 16MB). This method was commonly used on Windows 3.x applications to produce a flat memory space, although as the OS itself was still 16-bit, API calls could not be made with 32-bit instructions. Thus, it was still necessary to place all code that performs API calls in 64k segments.
 
Once 286 protected mode is invoked, it could not normally be exited except by performing a hardware reset. Machines following the rising [[IBM PC/AT]] standard could feign a reset to the CPU via the standardised keyboard controller, but this was significantly sluggish. Windows 3.x worked around both of these problems by intentionally triggering a [[triple fault]] in the interrupt-handling mechanisms of the CPU, which would cause the IBM AT-compatible hardware to reset the CPU, nearly instantly, thus causing it to drop back into real mode.<ref>{{Cite web|url=http://blogs.msdn.com/b/larryosterman/archive/2005/02/08/369243.aspx|title = DevBlogs}}</ref>
drop back into real mode.<ref>{{Cite web|url=http://blogs.msdn.com/b/larryosterman/archive/2005/02/08/369243.aspx|title = DevBlogs}}</ref>
 
=== Detailed segmentation unit workflow ===