Английская Википедия:A20 line
Шаблон:Short description Шаблон:Use dmy dates Шаблон:Use list-defined references
The A20, or address line 20, is one of the electrical lines that make up the system bus of an x86-based computer system. The A20 line in particular is used to transmit the 21st bit on the address bus.
A microprocessor typically has a number of address lines equal to the base-two logarithm of the number of words in its physical address space. For example, a processor with 4 GB of byte-addressable physical space requires 32 lines (log2(4 GB) = log2(232 B) = 32), which are named A0 through A31. The lines are named after the zero-based number of the bit in the address that they are transmitting. The least significant bit is first and is therefore numbered bit 0 and signaled on line A0. A20 transmits bit 20 (the 21st bit) and becomes active once addresses reach 1 MB, or 220.
Overview
Шаблон:See also The Intel 8086, Intel 8088, and Intel 80186 processors had 20 address lines, numbered A0 to A19; with these, the processor can access 220 bytes, or 1 MB. Internal address registers of such processors only had 16 bits. To access a 20-bit address space, an external memory reference was made up of a 16-bit offset address added to a 16-bit segment number, shifted 4 bits to the left so as to produce a 20-bit physical address. The resulting address is equal to segment × 16 + offset.[1] There are many combinations of segment and offset that produce the same 20-bit physical address. Therefore, there were various ways to address the same byte in memory.[2] For example, here are four of the 4096 different segment:offset combinations, all referencing the byte whose physical address is 0x000FFFFF (the last byte in 1 MB-memory space):
- F000:FFFF
- FFFF:000F
- F555:AAAF
- F800:7FFF
Referenced the last way, an increase of one in the offset yields F800:8000, which is a proper address for the processor, but since it translates to the physical address 0x00100000 (the first byte over 1 MB), the processor would need another address line for actual access to that byte. Since there is no such line on the 8086 line of processors, the 21st bit above, while set, gets dropped, causing the address F800:8000 to "wrap around"[1] and to actually point to the physical address 0x00000000.
When IBM designed the IBM PC AT (1984) machine, it decided to use the new higher-performance Intel 80286 microprocessor. The 80286 could address up to 16 MB of system memory in protected mode. However, the CPU was supposed to emulate an 8086's behavior in real mode, its startup mode, so that it could run operating systems and programs that were not written for protected mode. The 80286 did not force the A20 line to zero in real mode, however. Therefore, the combination F800:8000 would no longer point to the physical address 0x00000000, but to the address 0x00100000. As a result, programs relying on the address wrap around would no longer work. To remain compatible with such programs, IBM decided to correct the problem on the motherboard.
That was accomplished by inserting a logic gate on the A20 line between the processor and system bus, which got named Gate-A20. Gate-A20 can be enabled or disabled by software to allow or prevent the address bus from receiving a signal from A20. It is set to non-passing for the execution of older programs that rely on the wrap-around. At boot time, the BIOS first enables Gate-A20 when it counts and tests all of the system memory, and then disables it before transferring control to the operating system.
Originally, the logic gate was a gate connected to the Intel 8042 keyboard controller.[1] Controlling it was a relatively slow process. Other methods have since been added to allow more efficient multitasking of programs that require this wrap-around with programs that access all of the system memory. There are multiple methods to control the A20 line.[3]
Disconnecting A20 would not wrap all memory accesses above 1 MB, just those in the 1–2 MB, 3–4 MB, 5–6 MB, etc. ranges. Real-mode software cared only about the area slightly above 1 MB, so the Gate-A20 line was enough.
Enabling the Gate-A20 line is one of the first steps that a protected-mode x86 operating system does in the bootup process, often before control has been passed to the kernel from the bootstrap (in the case of Linux, for example).
Virtual 8086 mode, introduced with the Intel 80386, allows the A20 wrap-around to be simulated by using the virtual memory facilities of the processor; physical memory may be mapped to multiple virtual addresses. Thus, the memory mapped at the first megabyte of virtual memory may be mapped again in the second megabyte of virtual memory. The operating system may intercept changes to Gate A20 and make corresponding changes to the virtual-memory address space, which also makes irrelevant the efficiency of Gate-A20 line toggling.
A20 gate
Controlling the A20 line was an important feature at one stage in the growth of the IBM PC architecture, as it added access to an additional 65,520 bytes (64 KB − 16 bytes) of memory in real mode, without significant software changes.
In what was arguably a "hack", the A20 gate was originally part of the keyboard controller on the motherboard, which could open or close it depending on what behavior was desired.[4]
In order to keep full compatibility with the Intel 8086, the A20 gate was still present in Intel CPUs until 2008.[5] As the gate was initially closed right after boot, protected-mode operating systems typically opened the A20 gate early during the boot process to never close it again. Such operating systems had no compatibility reasons for keeping it closed, and they gained access to the full range of physical addresses available by opening it.
The Intel 80486 and Pentium added a special pin named A20M#, which when asserted low forces bit 20 of the physical address to be zero for all on-chip cache- or external-memory accesses. It was necessary, since the 80486 introduced an on-chip cache and so masking this bit in external logic was no longer possible. Software still needs to manipulate the gate and must still deal with external peripherals (the chipset) for that.[6]
The PC System Design Guide PC 2001 removes compatibility for the A20 line: "If A20M# generation logic is still present in the system, this logic must be terminated such that software writes to I/O port 92, bit 1, do not result in A20M# being asserted to the processor."[7]
Support for the A20 gate was changed in the Nehalem microarchitecture (some sources incorrectly claim that A20 support was removed). Rather than the CPU having a dedicated A20M# pin that receives the signal whether or not to mask the A20 bit, it has been virtualized so that the information is sent from the peripheral hardware to the CPU using special bus cycles.Шаблон:Citation needed From a software point of view, the mechanism works exactly as before, and an operating system must still program external hardware (which in-turn sends the aforementioned bus cycles to the CPU) to disable the A20 masking.Шаблон:Citation needed
Intel no longer supports the A20 gate, starting with Haswell. Page 271 of the Intel System Programmers Manual Vol. 3A from June 2013 states: "The functionality of A20M# is used primarily by older operating systems and not used by modern operating systems. On newer Intel 64 processors, A20M# may be absent."[8]
A20 handler
The A20 handler is IBM PC memory manager software that controls access to the high memory area (HMA). Extended-memory managers usually provide this functionality. A20 handlers are named after the 21st address line of the microprocessor, the A20 line.
In DOS, HMA managers such as HIMEM.SYS have the "extra task" of managing A20. HIMEM.SYS provided an API for opening/closing A20. DOS itself could use the area for some of its storage needs, thereby freeing up more conventional memory for programs. That functionality was enabled by the DOS=HIGH
or HIDOS=ON
directives in the CONFIG.SYS configuration file.
Шаблон:AnchorAffected programs
Since 1980, the address wrap was internally used by 86-DOS and MS-DOS to implement the DOS CALL 5 entry point at offset +5 to +9 (which emulates the CP/M-80-style CALL 5 BDOS API entry point at offset +5 to +7) in the Program Segment Prefix (PSP) (which partially resembles CP/M-80's zero page).[9][10] This was, in particular, utilized by programs machine-translated from CP/M-80 through assembly language translators[9] like Seattle Computer Products' TRANS86.[11] The CALL 5 handler this entry point refers to resides at the machine's physical address 0x000000C0 (thereby overlapping the four bytes of the interrupt service routine entry point reserved for INT 30h and the first byte of INT 31h in the x86 real mode interrupt vector table).[12][13][14] However, by the design of CP/M-80, which loaded the operating system immediately above the memory available for the application program to run in, the 8080/Z80 16-bit target address stored at offset +6 to +7 in the zero page could deliberately also be interpreted as the size of the first memory segment.[9] In order to emulate this in DOS with its 8086 segment:offset addressing scheme, the far call entry point's 16-bit offset had to match this segment size (i.e. 0xFEF0), which is stored at offset +6 to +7 in the PSP, overlapping parts of the CALL 5.[13][14] The only way to reconcile these requirements was to choose a segment value that, when added to 0xFEF0, results in an address of 0x001000C0, which, on an 8086, wraps around to 0x000000C0.[15][12][14]
A20 had to be disabled for the wraparound to occur and DOS programs using this interface to work. Newer DOS versions which can relocate parts of themselves into the HMA, typically craft a copy of the entry point at FFFF:00D0 in the HMA (which again resolves to physical 0x001000C0), so that the interface can work without regard to the state of A20.[14][16]
One program known to use the CALL 5 interface is the DOS version of the Small-C compiler.[17] Also, the SPELL utility in Microsoft's Word 3.0 (1987) is one of the programs depending on the CALL 5 interface to be set up correspondingly.[18] Sun Microsystems' PC-NFS (1993) requires the CALL 5 fix-up as well.[16]
Also, to save program space,[1] a trick was used by some BIOS and DOS programmers, for example, to have one segment that has access to program data (such as from F800:0000 to F800:7FFF, pointing to the physical addresses 0x000F8000–0x000FFFFF), as well as the I/O data (such as the keyboard buffer) that was located in the first memory segment (with addresses F800:8000 to F800:FFFF pointing to the physical addresses 0x00000000 to 0x00007FFF).
This trick works for as long as the code isn't executed in low memory, the first 64 KB of RAM, a condition that was always true in older DOS versions without load-high capabilities.
With the DOS kernel relocated into higher memory areas, low memory increasingly became available for programs, causing those depending on the wraparound to fail.[19] The executable loaders in newer versions of DOS attempt to detect some common types of affected programs and either patch them on-the-fly to function also in low memory[20] or load them above the first 64 KB before passing execution on to them.[20] For programs, which are not detected automatically, LOADFIX[21] or MEMMAX -L[21] can be used to force programs to be loaded above the first 64 KB.
The trick was utilized by IBM/Microsoft Pascal itself as well as by programs compiled with it,[22][23][10][17] including Microsoft's MASM.[17] Other commonly used development utilities using this were executable compressors like Realia's Spacemaker[20] (written by Robert B. K. Dewar in 1982 and used to compress early versions of the Norton Utilities[24][25][26][27]) and Microsoft's EXEPACK[19][20][1][28][17] (written by Reuben Borman in 1985) as well as the equivalent /E[XEPACK] option in Microsoft's LINK 3.02 and higher.[19][1][28][26] Programs processed with EXEPACK would display a "Packed file is corrupt" error message.[1][20][28]
Various third-party utilities exist to modify compressed executables either replacing the problematic uncompression routine(s) through restubbing, or attempting to expand and restore the original file.
Modern Legacy BIOS boot loaders (such as GNU GRUB) use the A20 line.[3] UEFI boot loaders use 32-bit protected mode or 64-bit long mode.
See also
- Bug compatibility[20]
- Computer storage
- High memory area (HMA)
- LOADFIX (CONFIG.SYS directive) (PTS-DOS)
- Incomplete address decoding
- Boot loaders
References
Further reading
- ↑ 1,0 1,1 1,2 1,3 1,4 1,5 1,6 Ошибка цитирования Неверный тег
<ref>
; для сносокPaul_2002_HMA
не указан текст - ↑ Ошибка цитирования Неверный тег
<ref>
; для сносокPaul_2002_SEGOFS
не указан текст - ↑ 3,0 3,1 Ошибка цитирования Неверный тег
<ref>
; для сносокOSWiki
не указан текст - ↑ Ошибка цитирования Неверный тег
<ref>
; для сносокShanley_1995_ISA
не указан текст - ↑ Шаблон:Cite web
- ↑ Ошибка цитирования Неверный тег
<ref>
; для сносокShanley_1996_Protected_mode
не указан текст - ↑ Шаблон:Cite book
- ↑ Ошибка цитирования Неверный тег
<ref>
; для сносокIntel_2013
не указан текст - ↑ 9,0 9,1 9,2 Ошибка цитирования Неверный тег
<ref>
; для сносокSCP_1980_86-DOS-PM
не указан текст - ↑ 10,0 10,1 Ошибка цитирования Неверный тег
<ref>
; для сносокMicrosoft_1985_US4779187
не указан текст - ↑ Ошибка цитирования Неверный тег
<ref>
; для сносокTaylor_1982_Translators
не указан текст - ↑ 12,0 12,1 Ошибка цитирования Неверный тег
<ref>
; для сносокSchäpers_1991_DOS5
не указан текст - ↑ 13,0 13,1 Ошибка цитирования Неверный тег
<ref>
; для сносокRBIL_2000_PSP
не указан текст - ↑ 14,0 14,1 14,2 14,3 Ошибка цитирования Неверный тег
<ref>
; для сносокNecasek_2011_CALL5
не указан текст - ↑ Ошибка цитирования Неверный тег
<ref>
; для сносокNorton_1985
не указан текст - ↑ 16,0 16,1 Ошибка цитирования Неверный тег
<ref>
; для сносокCaldera_1997_PC-NFS
не указан текст - ↑ 17,0 17,1 17,2 17,3 Ошибка цитирования Неверный тег
<ref>
; для сносокNecasek_2018_A20
не указан текст - ↑ Ошибка цитирования Неверный тег
<ref>
; для сносокParsons_1987_SPELL
не указан текст - ↑ 19,0 19,1 19,2 Ошибка цитирования Неверный тег
<ref>
; для сносокSchulman_1994_Undocumented-DOS
не указан текст - ↑ 20,0 20,1 20,2 20,3 20,4 20,5 Ошибка цитирования Неверный тег
<ref>
; для сносокPaul_2002_EXEC
не указан текст - ↑ 21,0 21,1 Ошибка цитирования Неверный тег
<ref>
; для сносокPaul_1997_NWDOSTIP
не указан текст - ↑ Ошибка цитирования Неверный тег
<ref>
; для сносокIBM_1981_Pascal
не указан текст - ↑ Ошибка цитирования Неверный тег
<ref>
; для сносокMicrosoft_1981_Pascal
не указан текст - ↑ Ошибка цитирования Неверный тег
<ref>
; для сносокCambridge
не указан текст - ↑ Ошибка цитирования Неверный тег
<ref>
; для сносокRealia_1983_SM
не указан текст - ↑ 26,0 26,1 Ошибка цитирования Неверный тег
<ref>
; для сносокDewar_1984
не указан текст - ↑ Ошибка цитирования Неверный тег
<ref>
; для сносокNecasek_2018_SM
не указан текст - ↑ 28,0 28,1 28,2 Ошибка цитирования Неверный тег
<ref>
; для сносокNecasek_2018_EXEPACK
не указан текст
- Английская Википедия
- Страницы с неработающими файловыми ссылками
- X86 memory management
- Memory expansion
- X86 architecture
- IBM PC compatibles
- Страницы, где используется шаблон "Навигационная таблица/Телепорт"
- Страницы с телепортом
- Википедия
- Статья из Википедии
- Статья из Английской Википедии
- Страницы с ошибками в примечаниях