Could the Intel 8086 CPU have many segments in memory of the same type?

Question

The Intel 8086 CPU could address up to 1 MB of memory using segmentation, and this CPU have 4 segment registers, which are CS and SS and DS and ES.

Each segment in memory can have a maximum size of 64 KB, which means that if all 4 segment registers are used, then 256 KB of memory would be used, which leaves 768 KB of memory unused.

So how were the remaining 768 KB of memory used? was it possible to have many segments in memory of the same type, for example could we have 2 stack segments in memory, and we would modify the SS register whenever we want to use a different stack segment?

Answer 1

Segment registers can be changed, thus allowing access to full address space.

In addition to doing this ad hoc, there are different ways to model this, called memory models:

• small: code and data both reside in one segment, all code and data pointers are 16bit
• medium: single data segment, multiple code segments (code pointers 32bit)
• compact: single code segment, multiple data segments (data pointers 32bit)
• large: multiple code and data segments (all pointers 32bit)

16bit pointers consist of offset only, and are called near pointers. 32bit pointers consist of segment and offset, and are called far pointers.

For small and medium memory models, stack and data segments were always the same. This allowed accessing local and global variables as well as heap allocated memory within same segment and thus with near pointers.

Using far pointers is slower as segment registers need to be modified each time they are used, so their use is discouraged unless explicitly needed.

Answer 2

The 8086 has 20 address pins so can access 1 MB of memory.  To be clear, the 20 bit address space is linear, and the memory subsystem doesn't know about segmentation or segment registers — it just sees the 20 address pins.

The values put on the 20 address pins are generated by segment register * 16 + offset, where offset comes from a regular register or other addressing mode.

It is the programming model that is awkward since it is basically a 16-bit processor.  To access more you need to hold/store at least 20 bits per pointer, and rounding up pointer size to 32-bits is the most practical.  For pointers larger than 16-bits, pointer dereference and pointer assignment require multiple instruction sequences (e.g. dereference involves setting segment registers).

@tuomas nicely details the various programming model options.

Answer 3

As already discussed, the 8086's memory addressing is a little... weird.

The hardware addressing was 20-bit and bytewise, which gives you the 2²⁰ addressable bytes (1 MiB).

To the software side, this was exposed as a segment (later, when the 80286 introduced protected mode, renamed a selector, but by default in real mode selectors were set up to work identically to segments) and an offset.

The physical address was generated by taking the segment, left-shifted by four bits (not multiplied by four, as another answer claims), and then adding the offset, then taking the lowest (most significant) 20 bits of the result.

It follows that any given physical memory address can be accessed via a number of different segment:offset pairs. There is no difference to the CPU-RAM interface between, say, F000:FFF0 and FFFF:0. (We can see this as F000<<4 becomes F0000, add FFF0 gives FFFF0; likewise, FFFF<<4 is FFFF0, add 0 gives FFFF0.)

As a consequence, it also follows that segments can overlap. In the above example, segments F000h and FFFFh overlap at address FFFF0h. In general, every segment selects a sliding 64 KiB window of the 1 MiB address space, shifted 16 bytes for each segment.

Memory models are a distraction, here; they mostly influence which segment value is the default for a particular type of operation, and which type of addressing is normally used.

To access a particular physical address, generally speaking, an appropriate segment register is loaded with the correct segment, and then a normal segment:offset access is performed via that segment register. Some instructions (such as jumps) can or even require the programmer to bypass the segment load operation and specify the segment directly in the instruction; other instructions can use only a specific segment register.

Since loading a segment register is a relatively invasive operation (as it changes global CPU state which you'll potentially need to reset before doing something else), it's something you'd try to avoid. By carefully choosing how you're addressing memory, many segment changes could be avoided, or restricted to the extra segment register, ES.

The CPU doesn't care about the type of segment (on the 8086/8088, there is nothing to mark a stack segment as different from a code or data segment; features like NX, or read-only segments, came later), but some operations have restrictions on which segment registers they can be used with. For example, you cannot perform an intersegment jump instruction into code pointed at by DS, but that's a restriction of the jump instruction, not the CPU. If for some strange reason you really want to jump to DS:IP+4, you just need to put that address in a place where a jump instruction can use it; there is no need to do anything to the memory itself.

Back in the day, the ability of the 8086/8088 to provide these different windows into the address space was sold as a feature by Intel, proposing that it would ease the development of multitasking or multiuser environments. For example, from the iAPX 86/88 user's manual, page 2-11:

The segmented structure of the 8086/8088 memory space supports modular software design by discouraging huge, monolithic programs. The segments also can be used to advantage in many programming situations. Take, for example, the case of an editor for several on-line terminals. A 64k text buffer (probably an extra segment) could be assigned to each terminal. A single program could maintain all the buffers by simply changing register ES to point to the buffer of the terminal requiring service.

Answer 4

Before "protected memory," all bytes were basically the same as far as the CPU was concerned. The segment registers are a lot like "bank selectors" that you'd see in other segmented memory schemes, except that they overlapped every 16 bytes. So, if you needed to use 128KB of RAM for a game data file, you would just change the DS register between two or more values to choose which 64k chunk of the 128k file you were reading/writing. Of course, developers had to be careful to either use MS-DOS or BIOS routines to make sure they didn't accidentally overwrite the Interrupt Vector Table, etc, but aside from that, the CPU and memory controller didn't actually enforce many sanity checks directly.

For example, MS-DOS's "COM" format was just raw machine code without any headers. Before execution, CS, DS, and SS were all set to the same value. However, a developer could write code to move SS up 64k, giving access to a full-sized stack, and then move DS around as they like to load and save memory as they'd like. The EXE format had additional headers before the machine code, allowing CS, DS, and SS to be different initially. From there, if you were using a higher level language (C was common back then), the langage's memory manager could change CS and SS as necessary to access more than 64k. The only limit is that you could only access 64k of memory per register at one time, without changing the segment register.

Answer 5

8086 assemblers and compilers supported different memory models where a program could have one or more code segments combined with one or more data segments. For example, a small model program would have one code segment (cs) and one data segment (ds/es). A large model program would have multiple code segments (cs, using a far jump), multiple data segments (with the segment in one of ds or es). The number (one/multiple) of stack segments would generally match the number of data segments (one/multiple).