x86 memory segmentation. x86 memory segmentation refers to the implementation of memory segmentation in the Intel x86 computer instruction set architecture. Segmentation was introduced on the Intel 8086 in 1978 as a way to allow programs to address more than 64 KB (65,536 bytes) of memory. The Intel 80286 introduced a second version of segmentation in 1982 that added support for virtual memory and memory protection. At this point the original model 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. The choice of segment is normally defaulted by the processor according to the function being executed. Real mode[edit] Three segments in real mode memory (click on image to enlarge). In real mode or V86 mode, a segment is always 65,536 bytes in size (using 16-bit offsets). The effective 20-bit address space of real mode limits the addressable memory to 220 bytes, or 1,048,576 bytes (1 MB). Local Descriptor Table. The Local Descriptor Table (LDT) is a memory table used in the x86 architecture in protected mode and containing memory segment descriptors: start in linear memory, size, executability, writability, access privilege, actual presence in memory, etc.
The LDT is the sibling of the Global Descriptor Table (GDT) and defines up to 8192 memory segments accessible to programs - note that unlike the GDT, the zeroeth entry is a valid entry, and can be used like any other LDT entry. Also note that unlike the GDT, the LDT cannot be used to store certain system entries: TSSs or LDTs. Call Gates and Task Gates are fine, however. History[edit] On x86 processors not having paging features, like the Intel 80286, the LDT is essential to implementing separate address spaces for multiple processes. There will be generally one LDT per user process, describing privately held memory, while shared memory and kernel memory will be described by the GDT.
Creating shared memory through the GDT has some drawbacks. Global Descriptor Table. The Global Descriptor Table or GDT is a data structure used by Intel x86-family processors starting with the 80286 in order to define the characteristics of the various memory areas used during program execution, including the base address, the size and access privileges like executability and writability. These memory areas are called segments in Intel terminology. The GDT can hold things other than segment descriptors as well. Every 8-byte entry in the GDT is a descriptor, but these can be Task State Segment (or TSS) descriptors, Local Descriptor Table (LDT) descriptors, or Call Gate descriptors.
The last one, Call Gates, are particularly important for transferring control between x86 privilege levels although this mechanism is not used on most modern operating systems. There is also an LDT or Local Descriptor Table. The LDT is supposed to contain memory segments which are private to a specific program, while the GDT is supposed to contain global segments. GDT in 64-bit[edit] [edit] Task State Segment. Processor register stateI/O port permissionsInner-level stack pointersPrevious TSS link All this information should be stored at specific locations within the TSS as specified in the IA-32 manuals.
Location of the TSS[edit] The TSS may reside anywhere in memory. A special segment register called the task register (TR) holds a segment selector that points to a valid TSS segment descriptor which resides in the GDT (a TSS descriptor may not reside in the LDT). Therefore, to use a TSS the following must be done by the operating system kernel: Create a TSS descriptor entry in the GDTLoad the TR with a segment selector for that segmentAdd information to the TSS in memory as needed Task register[edit] The TR register is a 16-bit register which holds a segment selector for the TSS. Register states[edit] The TSS may contain saved values of all the x86 registers. I/O port permissions[edit] Inner-level stack pointers[edit] Previous TSS link[edit] Use of TSS in Linux[edit] Exceptions related to the TSS[edit]
Process control block. Role[edit] The role of the PCBs is central in process management: they are accessed and/or modified by most OS utilities, including those involved with scheduling, memory and I/O resource access and performance monitoring. It can be said that the set of the PCBs defines the current state of the operating system. Data structuring for processes is often done in terms of PCBs. For example, pointers to other PCBs inside a PCB allow the creation of those queues of processes in various scheduling states ("ready", "blocked", etc.) that we previously mentioned. Structure[edit] In modern sophisticated multitasking systems, the PCB stores many different items of data, all needed for correct and efficient process management.[1] Though the details of these structures are obviously system-dependent, we can identify some very common parts, and classify them in three main categories: Process identification dataProcessor state dataProcess control data Location[edit] See also[edit] Thread control block (TCB)
Context switch. Context switches are usually computationally intensive, and much of the design of operating systems is to optimize the use of context switches. Switching from one process to another requires a certain amount of time for doing the administration - saving and loading registers and memory maps, updating various tables and lists etc. When to switch? [edit] There are three potential triggers for a context switch: Multitasking[edit] Interrupt handling[edit] Modern architectures are interrupt driven. User and kernel mode switching[edit] When a transition between user mode and kernel mode is required in an operating system, a context switch is not necessary; a mode transition is not by itself a context switch.
Steps[edit] In a switch, the state of the first process must be saved somehow, so that, when the scheduler gets back to the execution of the first process, it can restore this state and continue. Software vs hardware context switching[edit] References[edit] External links[edit] Translation lookaside buffer. The TLB is sometimes implemented as content-addressable memory (CAM). The CAM search key is the virtual address and the search result is a physical address. If the requested address is present in the TLB, the CAM search yields a match quickly and the retrieved physical address can be used to access memory. This is called a TLB hit. If the requested address is not in the TLB, it is a miss, and the translation proceeds by looking up the page table in a process called a page walk. The page walk requires a lot of time when compared to the processor speed, as it involves reading the contents of multiple memory locations and using them to compute the physical address.
After the physical address is determined by the page walk, the virtual address to physical address mapping is entered into the TLB. The operation of more common TLB implementations is using hash tables,[citation needed] similarly to the CAM implementations.[2] Overview[edit] The virtual memory is the space seen from a process. CPUID. The CPUID opcode is a processor supplementary instruction (its name derived from CPU IDentification) for the x86 architecture. It was introduced by Intel in 1993 when it introduced the Pentium and SL-Enhanced 486 processors.[1] Prior to the general availability of the CPUID instruction, programmers would write esoteric machine code which exploited minor differences in CPU behavior in order to determine the processor make and model.[2][3] Outside the x86 family, developers are sometimes still required to use esoteric processes to determine the variations in CPU design that are present.
While the CPUID instruction is specific to the x86 architecture, other architectures often provide on-chip registers which can be read to obtain the same sorts of information provided by this instruction. Calling CPUID[edit] In assembly language the CPUID instruction takes no parameters as CPUID implicitly uses the EAX register. EAX=0: Highest Function Parameter[edit] EAX=0: Get vendor ID[edit] "AMDisbetter!
"