How does x86 real-mode segments overlap help memory saving?

Question

I'm teaching my 12 y.o. 8086 assembly language and yesterday we were talking memory, addressing and segmentation. I showed him how segments can be visualized as a sequence of overlapping 64Kb blocks starting on 16 byte boundaries, with the offset being an 8080-style pointer within a segment. Then he asked a question I could not answer: why (what for, with what purpose) do they overlap?

Trying to research this question I found many copies of the 20 bit math, and a few vague mentions of some memory savings this scheme presumably allows. Can somebody elaborate on the memory saving part? Or any other ways to take practical advantage of the overlaps?

Qadi

Segmented memory is no fun to work with regardless what age you are ;-) If I was the teacher I would have gone straight into 32-bit flat memory model instead. Or a 8-bit processor like Z80. – Natachanatal

@VilleKrumlinde yeah, we have started from 8080 which had no such silly issues. Whenever I study or teach I always like to emphasize the historical perspective, hence my hesitation to skip over the quirks. – Qadi

@VilleKrumlinde: The 8086 real-mode segment design is IMHO vastly underappreciated, largely because C lacks the facilities to take best advantage of it. If C provided a means of declaring pointers whose offset part was guaranteed to be zero, and had allocation methods that returned such pointers, the genius of real-mode segmentation would have been much more apparent. – Phrygian

Related: What are Segments and how can they be addressed in 8086 mode? discusses letting segments overlap or not – Prau

Answer 1

The less overlap, the less choice you'll have over where a segment starts in physical memory. That creates gaps between segments that are not useful, thus wasting memory. The design choice never creates a gap larger than 15 bytes. That's overdoing it a bit perhaps but 8086 was designed in an era where 1 megabyte was enough for everybody. And buying 64 kilobytes put a rather large dent in your budget. Precious enough to not want to waste on gaps.

Jig

Answer 2

Memory savings is entirely the wrong way to look at it IMO. That processor came out at a time when 16-bit address space was getting really tight. Other 16-bit address space processors were having bank switching methods tacked on after the fact. A 20 bit address space was a sizeable approvement (24, or 32-bit was just crazy talk at the time). Rather than tack on an external bank switching (which is a pain to program for), they used registers. Well, guess what, the processor is 16-bit internally, so might as well use 16-bit registers. Now, getting 20 bits out of a pair of 16-bit registers is an interesting problem. Using the segment as basically paragraph alignment gives you the full range (plus a little overrun, but that's an entirely different problem) in the most flexible way (remember the pain of bankswitching that I mentioned? It's primarily because of not being able to do it in a fine-grained manner).

Batfish

This is the 20-bit part of the story. It answers the question "what constraints led to this design decision". I'm asking a different question: "what are the advantages of this design decision beyond it satisfying the constraints". – Qadi

I thought I covered that too. To put it more simply, the only real advantage is that you can generate single code segment non-relocatable images actually BE relocateable (without linking/fixups) by not permitting segment register manipulation for the code segment. AKA the ".com" format executable in DOS. – Batfish

@BrianKnoblauch: In resource-constrained code, being able to identify any paragraph-aligned memory block with a two-byte value may be more useful than having to use three or four bytes for the purpose. In assembly code, if one needs pointers to many objects, being able to use two bytes per pointer instead of four can easily make up for memory wasted between by object-size rounding. Too bad C doesn't have a two-byte "segment-only" pointer type. – Phrygian

Answer 3

Suppose you own a valet parking service in a long, narrow alley, so the vehicles are all parked parallel-parking style. Some of your customers drive cars and use only 1 space. Others drive stretch limos and require 2 spaces. One way of parking the vehicles would be to assign 2 spaces to each vehicle, regardless of size. Your claim tickets would say "Vehicle is parked starting in space 0 (maximum vehicle size is 2 spaces)" or "starting in space 2", or "starting in space 4", etc.

This would work, but it wastes spaces because you are reserving 2 spaces for cars which need only 1. So instead, you pack the vehicles together, with cars taking only one space and limos taking two. Your employees know that car takes only one space, so if a ticket says "starting in space 1 (maximum vehicle size is 2 spaces)" they know that "The car is in space 1, and space 2 belongs to somebody else." The car's space 2 actually overlaps the limo parked in spaces 2 and 3, but it would be a bad idea to use it or you're going to dent the limo.

Heading

Thanks for the analogy! I guess I could employ buses, trucks and other varisized vehicles. – Qadi