[mschaef]

There is no such thing as a "2MB program".... all you have is a program composed of <=64K segments, which are easy enough to fit into the hole.

If you do need something approaching a 2MB block of memory, you don't need a contiguous range of memory, what you need is a contiguous range of selectors, which is a different (and probably easier) problem to solve.

[PunchyHamster]

but without virtual memory you can't move them around and so program that wants to allocate 2MB of 64k segments can't run if there is no 2MB continuos hole

[mschaef]

I should preface this by saying I'm taking about x86 segmentation in general. On the 8086 you're right, but the 8086 can't address 2MB of memory to begin with. On the 80286 in protected mode, the situation is different in the way I'm about to describe.

The memory itself doesn't have to be contiguous.

2MB of 64K segments maps to 32 segments. So you need 32 locations in physical memory capable of storing 64K.

The programming model for addressing that block of memory necessarily includes both segment selectors and offsets. The segment selectors are indices into a segment table that contains the base address of each of the 32 segments. As long as the segment selectors themselves can be allocated contiguously in the segment table, you have enough to be able to compute which segment you need for which address in the 2MB range. It's the indirection through the segments table that maps it to physical addresses that do not need to be contiguous.

Raymond Chen talks a bit about how it worked in Windows 3.x here: https://devblogs.microsoft.com/oldnewthing/20171113-00/?p=97...

[senfiaj]

>> 8086 can't address 2MB of memory

This was just for illustration, not claiming that actual 8086 does this.

>> Raymond Chen talks a bit about how it worked in Windows 3.x here: https://devblogs.microsoft.com/oldnewthing/20171113-00/?p=97...

And this is the problem, it was very painful just to walk through a 200 KB buffer. This required compiler/runtime tricks, different selector increments in real vs protected mode, and special pointer types. Paging later made this kind of thing look like one flat array, a thing segmentation could not: making non-contiguous physical RAM appear contiguous to the program.

[mschaef]

> And this is the problem, it was very painful just to walk through a 200 KB buffer. This required compiler/runtime tricks, different selector increments in real vs protected mode, and special pointer types.

Most of that could be (and often was) hidden by the tooling. If you needed to bypass it, you could, but you didn't need to. That's not very different from today... there's a lot of hidden magic that can be bypassed if you need to for whatever reason.

I'd argue that these are useful engineering abstractions that made the best of a less than ideal situation. (The reality of the world being that there are no "ideal" situations... you have to work with what you have at the moment to solve the problem you have. These days, I'd argue that a pointer into a 'flat' memory space is counter productive to the extent it hides issues around cache hierarchy, NUMA, etc. In 1986, we had to worry that a flat memory space looked discontiguous. In 2026, we have to worry the a discontiguous memory space looks flat.

[senfiaj]

>> In 2026, we have to worry the a discontiguous memory space looks flat.

Well, there are large/huge pages (2MiB/4MiB/1GiB) that reduce this problem.

[AnimalMuppet]

OK, but we spent a decade having to worry about this garbage, until the tooling finally caught up. You always had to keep it in the back of your mind if you wrote PC software. Even if you just ran PCs, you had to worry about the compatibility between your OS, your "DOS extender", and your programs.

There were literally millions of man-hours wasted on segment registers. A kludge that helped Intel conquer the world, but what a filthy, disgusting architecture, and what a waste of everybody's time and brain power.

[mschaef]

> OK, but we spent a decade having to worry about this garbage, until the tooling finally caught up.

This was less about tooling than it was about economics - there was 32-bit hardware available in the personal computer space in 1984, if not before. The issue was cost. In today's currency, a 32-bit capable Mac was $8,000 with 128K. The first 32-bit capable PC was closer to $20,000.

That's a heavy lift in a world where a segmented architecture machine costs a fraction of that amount, runs software you might already have, and works the same way as your co-worker's machine.

> There were literally millions of man-hours wasted on segment registers.

A software developer in 1986 was not forced to deal with segment registers... but they often chose to deal with them to gain access a (much) bigger audience of potential customers for their software.

> A kludge that helped Intel conquer the world, but what a filthy, disgusting architecture, and what a waste of everybody's time and brain power.

The other side of the coin is that (for reasons I state above), segmented architectures got more capable software into more hands more quickly. It arguably did a lot for end users.