Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

8086 Segmented Memory was a good idea

owl.billpg.com

Post reply on HN
Print view View original

51–60 of 150 posts

Re: 8086 Segmented Memory was a good idea

#51

Post by senfiaj »

mschaef wrote: post #46
PunchyHamster wrote: post #43

Earlier quoted context omitted.

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

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 progr…

>> 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.

Re: 8086 Segmented Memory was a good idea

#52

Post by mschaef »

porridgeraisin wrote: post #50
mschaef wrote: post #37

Earlier quoted context omitted.

> I had to use it to do image processing on a 256MB image buffer back in the 1980s in assembly language.... Give me a flat 32 bit memory address space any day (e.g. MC68000 around the same time.) Huh? There were no segmented x86 machines capable of addressing 256MB of RAM, aside from the 386 (maybe). If you had a 386 and the $130K of memory your statement implies, you probably also could afford a Unix (or something e…

Perhaps they meant KB?

That would make more sense. I was trying to imagine what sort of (custom?) hardware would accommodate that amount of memory back then. That was large storage even for mainframes the time. (The Cray 2 in the mid-1980's had 2GB, which was considered notably large.)

Re: 8086 Segmented Memory was a good idea

#53

Post by KellyCriterion »

wewewedxfgdf wrote: post #33
Ekaros wrote: post #31

Earlier quoted context omitted.

I really wonder if Unix is best we can do. Or is it also worst? So in the end two of the worst options won. It did make sense back in time. But could it have been replaced with something better later?

>> two of the worst options won What do you mean, which are the two? Sure, Windows is crappy by Linus and MacOS? They are both awesome.

Especially the enshittification over the decades: All the bloat (XBog Game Icon on Win Server - really?), their update politics tangled with higher hardware specs for running the same stuff slower than before.

I do not understand how can one crash their own product/baby that way - and no, this must be Hanlors Razors: They are doing it with (sophisticated) intend, not by accident (or coincidence)

Re: 8086 Segmented Memory was a good idea

#54

Post by rzzzt »

flohofwoe wrote: post #14
hexmiles wrote: post #8

What is the difference between the segmentation model used by Intel and the banking model used by a lot of consoles? I've worked with the code of a couple of NES and GBC games, and while banking could be annoying, I never saw it as a particularly difficult model to follow and use. It did require more planning for the various functionality, but it wasn't even the most complex or difficult thing about developing for co…

It's pretty much the same thing, except that all the memory mapping logic has moved from 'custom memory mapping hardware' into the CPU.

Banking also appeared on the platform in the form of EMS.

Re: 8086 Segmented Memory was a good idea

#55

Post by mschaef »

senfiaj wrote: post #51
mschaef wrote: post #46

Earlier quoted context omitted.

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 progr…

>> 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 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.

Re: 8086 Segmented Memory was a good idea

#56

Post by JdeBP »

KellyCriterion wrote: post #28
wewewedxfgdf wrote: post #19

I seem to recall at the time that flat memory was self evidently a better idea. It's not like people were sitting around going "gee I can't think of any better way to do memory addressing that this" until some genius suggests "how about flat?!?!?" Everyone knew flat was best but were stuck with 8086 crap.

-- Everyone knew flat was best but were stuck with 8086 crap.-- This! Thats one of the most interesting things to me: Actually very often in the IT-world, the worst competitor won the race while better solutions were known and available: Microsoft, Intel etc. Esp. that MS won for decades while making mainly a very bad OS, though they have some good enterprise products. How would the world look, if Unix/BSD would have…

There was a Microsoft operating system for protected mode 80286 in 1983. It was Xenix 286; it was basically 7th Edition Unix without the branding; and it was touted as the multiuser operating system that MS-DOS would be the gateway to. How would the world look if Microsoft had won the race? (-:

Re: 8086 Segmented Memory was a good idea

#57

Post by senfiaj »

mschaef wrote: post #55
senfiaj wrote: post #51

Earlier quoted context omitted.

>> 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 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 bypass…

>> 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.

Re: 8086 Segmented Memory was a good idea

#59

Post by AshamedCaptain »

st_goliath wrote: post #11

> 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…

I think you are missing the entire point of the article (which I kinda agree with), and just repeating the popular wisdom.

In the era a machine with "object addressing" sounded like a perfectly valid futuristic design (what a Lisp machine strived to be; I guess today you would call it tagged memory of some kind). The 8086 is not that, but the original design would have allowed to evolve it into something like that.

The article's point is that since programmers simply treated it as a sliding window (instead of an opaque object handle), the plan could not be implemented, and the half-assed thing became stuck.

Having seen other Intel RISC designs, I fully agree with the premise.

Re: 8086 Segmented Memory was a good idea

#60

Post by billpg »

AKSF_Ackermann wrote: post #12

The segment model seems clever if you assume that you never have an object that is larger than 64kb. And once you have that you need to care about segment overflow, pointer comparisons no longer work, everything now has to carry around segment+offset instead of just offset, and so on. And if you want an example of a >=64kb object - the html alone for that page is one.

Why would you ever want a single 64k object? That's like an entire machine's worth of memory!
Post reply on HN