8086 Segmented Memory Was a Good Idea.

Yet the article goes about the most ass backward way of explaining 8086 segments and constructs a convoluted mental picture of dividing memory into overlapping chunks.

It's really, really simple: segments on the 8086/88 are 64k sliding windows into an 1M address space. You can move them around at 16 byte granularity.

You need more than 64k for code + data? No problem, the CPU knows when it's fetching an instruction vs when it's fetching data, you can have two sliding windows: code (CS) and data (DS). Split them apart, and it's not much different than a Harvard-style machine and gives you access to more than 64k at a time.

Still need more? No problem, the CPU has a hardware stack with dedicated push/pop/call/ret instructions and a base pointer for stack indexing. It knows when it's accessing the stack, so we can split the data window into regular data (DS) and stack data (SS). Oh, you occasionally want to copy stuff between segments or somewhere else in memory? Well, to encode 3 segments we need 2 bits anyway, let's throw in an extra data window (ES) and some DS-to-ES copy instructions.

It was just a hack. Hack to delay migration to 32 bit architecture. Effective one, but hack nonetheless

286 could then use the next 4 bits from the segment register to allow 16 MB address space and 386 could use all of them for 4GB. And wouldn't it be nice if 386 had 64KB pages (1 segment)?

The original 20 bit vision of the 8086 was when memory was very expensive and they expected typical high end machines to have 128K of memory.

Intel’s assembler was designed so you could have up to 128K of code with a “shared” segment in the middle that either side could reach with near (16 bit only) pointers to call commonly shared routines, and more rarely executed code existed on either end.

In addition data could be its own segment, and/or memory mapped I/O outside of the 128K space.

But memory got so cheap that nobody bothered with this, and the performance gains of writing code that way wasn’t worth the effort. X86 code was compact enough most programs could cram their code into 64k anyway, or 64k per functional unit with calls between them being rare.

The real tragedy is they went for 20 bit instead of 24 bit. 8086 with 16MB of addressable space would have been a very different world and would have made little difference if there use. (Paragraphs would have been 256 bytes, the same size as a page; most data structures would have been fine with that.)

Need more than 64KB? Allocate two blocks.

How is that compatible with an array and a simple implementation of the index operator?

No, it wasn't

It's the "great idea" that sounds great 5 min in and horrible 10min afterwards

You know, kinda like using null as a string end character

But more importantly it kept the x86 world for too long in that dead end that was 8086 mode programming

"Oh if developers would just..." They won't. They haven't. And they will not ever.

In hindsight maybe a binary level translator from 8080 to 8086 would have worked better (and be simple enough)

Segmented memory (on hardware that supported segment permissions) was used to good effect in Multics as well.

Imagine if you could have done something like this:

   add  si, some-delta
   adsc es, 0

ADSC (add with segment carry) would do:

   segreg := segreg + imm + 1000h (if carry)

   segreg := segreg + imm  (no carry)

ADSC could have been adapted for the 286 with ease, as long as a specific layout of the segment descriptor tables was mandated (probably with 10h instead of 1000h in protected mode).

Edited slightly for clarity (ofs => imm). A normalizing instruction would be harder to do right for the 286 because you don't want to spend too many slots in the descriptor table(s) for a single memory object.

The segment thing and the convoluted different pointer math caused real gymnastics if you ever had data bigger than 64k... such as images.

I always thought of the segments as windows of 64k but moving between those windows, esp with the limited register set, required some real mental gymnastics.

Not to do a "The Amiga was ahead of its time" thing but as a reminder, 68000 has a flat 24-bit address.

What we needed, in hindsight, was to treat segments as true selectors — opaque handles with no arithmetic meaning. If you can’t assume the next segment is 16 bytes ahead, you’re forced to use segmentation as intended.

Except we couldn't. If we made each segment isolated from other, we would waste so much memory because memory are allocated in segment.

If we made each segment dynamic, we need something to manage them.

This "hindsight" is just a MMU in disguise.