Editing Intel 8086 (section)

===Segmentation===
{{See also|x86 memory segmentation}}
There are also four 16-bit [[x86 memory segmentation|segment]] registers (see figure) that allow the 8086 [[Central processing unit|CPU]] to access one [[megabyte]] of memory in an unusual way. Rather than concatenating the segment register with the address register, as in most processors whose address space exceeds their register size, the 8086 shifts the 16-bit segment four bits left before adding it to the 16-bit offset (16×segment + offset), therefore producing a 20-bit external (or effective or physical) address from the 32-bit segment:offset pair. As a result, any external address could be referred to by up to 2<sup>12</sup> = 4096 different segment:offset pairs.<ref>{{cite web |last1=Sedory |first1=Daniel B|title=The Segment:Offset Addressing Scheme |url=https://thestarman.pcministry.com/asm/debug/Segments.html |website=thestarman.pcministry.com |access-date=6 March 2025}}</ref>

{| style="margin-left:5em"
|-
| <code>&nbsp; </code><code style="background:#DED">0110 1000 1000 0111</code><code>0000</code>
| '''Segment''',
| 16 bits, shifted 4 bits left (or multiplied by 0x10)
|-
| <code>+ &nbsp;&nbsp;&nbsp;&nbsp; </code><code style="background:#DDF">1011 0100 1010 1001</code>
| '''Offset''',
| 16 bits
|- style="text-decoration:line-through"
| <code>&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code>
|
|-
| <code>&nbsp; </code><code style="background:#FDF">0111 0011 1101 0001 1001</code>
| '''Address''',
| 20 bits
|}

Although considered complicated and cumbersome by many programmers, this scheme also has advantages; a small program (less than 64&nbsp;KB) can be loaded starting at a fixed offset (such as 0000) in its own segment, avoiding the need for [[Relocation (computing)|relocation]], with at most 15&nbsp;bytes of alignment waste.

Compilers for the 8086 family commonly support two types of [[pointer (computer programming)|pointer]], ''near'' and ''far''. Near pointers are 16-bit offsets implicitly associated with the program's code or data segment and so can be used only within parts of a program small enough to fit in one segment. Far pointers are 32-bit segment:offset pairs resolving to 20-bit external addresses. Some compilers also support ''huge'' pointers, which are like far pointers except that [[pointer arithmetic]] on a huge pointer treats it as a linear 20-bit pointer, while pointer arithmetic on a far pointer [[integer overflow|wraps around]] within its 16-bit offset without touching the segment part of the address.

To avoid the need to specify ''near'' and ''far'' on numerous pointers, data structures, and functions, compilers also support "memory models" which specify default pointer sizes. The ''tiny'' (max 64K), ''small'' (max 128K), ''compact'' (data > 64K), ''medium'' (code > 64K), ''large'' (code,data > 64K), and ''huge'' (individual arrays > 64K) models cover practical combinations of near, far, and huge pointers for code and data. The ''tiny'' model means that code and data are shared in a single segment, just as in most 8-bit based processors, and can be used to build ''[[COM file|.com]]'' files for instance. Precompiled libraries often come in several versions compiled for different memory models.

According to Morse et al.,.<ref>{{cite journal |first1=Stephen P. |last1=Morse |first2=Bruce W |last2=Ravenel |first3=Stanley |last3=Mazor |first4=William B. |last4=Pohlman |title=Intel Microprocessors: 8008 to 8086 |journal=IEEE Computer |volume=13 |issue=10 |pages=42–60 |date=October 1980 |doi=10.1109/MC.1980.1653375 |s2cid=206445851 |url=https://stevemorse.org/8086history/8086history.doc}}</ref> the designers actually contemplated using an 8-bit shift (instead of 4-bit), in order to create a 16&nbsp;MB physical address space. However, as this would have forced segments to begin on 256-byte boundaries, and 1&nbsp;MB was considered very large for a microprocessor around 1976, the idea was dismissed. Also, there were not enough pins available on a low cost 40-pin package for the additional four address bus pins.

In principle, the address space of the x86 series ''could'' have been extended in later processors by increasing the shift value, as long as applications obtained their segments from the operating system and did not make assumptions about the equivalence of different segment:offset pairs.<ref group="note" >Some 80186 clones did change the shift value, but were never commonly used in desktop computers.</ref> In practice the use of "huge" pointers and similar mechanisms was widespread and the flat 32-bit addressing made possible with the 32-bit offset registers in the 80386 eventually extended the limited addressing range in a more general way.

The instruction stream is fetched from memory as words and is addressed internally by the processor to the byte level as necessary. An instruction stream queuing mechanism allows up to 6 bytes of the instruction stream to be queued while waiting for decoding and execution. The queue acts as a First-In-First-Out (FIFO) buffer, from which the Execution Unit (EU) extracts instruction bytes as required. Whenever there is space for at least two bytes in the queue, the BIU will attempt a word fetch memory cycle. If the queue is empty (following a branch instruction, for example), the first byte into the queue immediately becomes available to the EU.<ref name="8086Datasheet">{{cite web |title=8086 16-BIT HMOS Processor datasheet |url=https://cdn.datasheetspdf.com/pdf-down/8/0/8/8086_Intel.pdf |publisher=Intel |access-date=26 November 2021 |archive-date=26 November 2021 |archive-url=https://web.archive.org/web/20211126175101/https://cdn.datasheetspdf.com/pdf-down/8/0/8/8086_Intel.pdf |url-status=dead }}</ref>

====Porting older software====
Small programs could ignore the segmentation and just use plain 16-bit addressing. This allows [[8-bit computing|8-bit]] software to be quite easily ported to the 8086. The authors of most [[DOS]] implementations took advantage of this by providing an [[Application Programming Interface]] very similar to [[CP/M]] as well as including the simple ''.com'' executable file format, identical to CP/M. This was important when the 8086 and MS-DOS were new, because it allowed many existing CP/M (and other) applications to be quickly made available, greatly easing acceptance of the new platform.