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

41–50 of 150 posts

Re: 8086 Segmented Memory was a good idea

#41

Post by PunchyHamster »

Ekaros wrote: post #31
KellyCriterion wrote: post #28

Earlier quoted context omitted.

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

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?

"Better" is not one dimensional scale

Adding more features to OS is for some use cases a benefit, for other it's a barrier. For one it might be less work to get what you want ,for other it might be more code between you and hardware that just slows it down

Unix-like simplicity is exactly that, for some use cases directness is a benefit, for others it means extra work to do on top to get what you want.

If you just want a house, getting a raw foundation to work with is a lot to build on top, you have to bring the rest of the walls up yourself.

But if you want exactly the house you want, getting entirely different house to start with and changing it is far more work than starting from simple foundation and building up.

Overall unix "here is relatively simple operating system that doesn't force you but needs some things to be built on top to hit your use case" probably IS the best abstraction, despise not being "best" at really anything. There is reason we build houses from concrete and wood, and not carbon fiber and titanium alloys

Re: 8086 Segmented Memory was a good idea

#42

Post by simiones »

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.

There are many crappy design decisions in Unix, Posix, Linux, MacOS, that have been known and worked around for decades (see the Unix Hater's Handbook). One example would be async IO, which has been famously bad in Unix, and Linux alone has tried 2 different generations of solutions - with the newer one, io_uring, being suspiciously similar to Windows' decades old IOCP. Fork/exec is infamous as a needlessly complex process creation API, requiring huge effort in the kernel just to handle the most common case of simply launching a new process. The traditional Unix security paradigm of simple user based file permissions is extremely weak and has required numerous solutions on top to handle realistic security scenarios - e.g. to protect a user's files from being tampered in unexpected ways by a process launched by that user (SELinux, jails, namespaces, etc).

I agree that Windows is crappy, but that doesn't mean that Linux and MacOS aren't also crappy in their own ways (not to mention iOS, Android).

Re: 8086 Segmented Memory was a good idea

#43

Post by PunchyHamster »

mschaef wrote: post #39
senfiaj wrote: post #27

Earlier quoted context omitted.

Maybe (I think it's possible in protected mode), but it still has an allocation problem, imagine there are programs A, B, C in the memory. Later, A and C are unloaded, leaving 2 free holes, totaling in 2MB. Now you want to load a 2MB program, but there is no unfragmented 2MB free block. The only solution I see, is to shift some loaded programs, which might be slow and even risky. Paging makes this problem much easier…

There is no such thing as a "2MB program".... all you have is a program composed of 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.

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

Re: 8086 Segmented Memory was a good idea

#44

Post by peterfirefly »

Could have been fixed with an ADC-type instruction that operated on segments.

Imagine if you could have done something like this:

   add  si, some-delta
   adsc es, 0
in order to move a seg:ofs ptr forward by 'some-delta' bytes.

ADSC (add with segment carry) would do:

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

   segreg := segreg + imm  (no carry)
Maybe there should also have been an instruction to normalize a seg:ofs ptr (so the new offset was in the 0-15 range).

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.

Re: 8086 Segmented Memory was a good idea

#46

Post by mschaef »

PunchyHamster wrote: post #43
mschaef wrote: post #39

Earlier quoted context omitted.

There is no such thing as a "2MB program".... all you have is a program composed of 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.

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

Re: 8086 Segmented Memory was a good idea

#48

Post by j16sdiz »

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

Re: 8086 Segmented Memory was a good idea

#49

Post by peterfirefly »

gdwatson wrote: post #24
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…

It was a clever hack for porting existing code. But it doesn’t scale at all – you’ve just described adding four registers to a register-starved architecture in order to solve the issue for one CPU generation or so.

Segment prefixes were rarely needed and you didn't need to spend any of the precious mod/rm bits on segment registers. The GPR count was limited to 8 partly because of the 3 bits allocated to specifying them and partly because of limited die space. Segment registers only added slightly to the latter cost.

Re: 8086 Segmented Memory was a good idea

#50

Post by porridgeraisin »

mschaef wrote: post #37
RagnarD wrote: post #35

I had to use it to do image processing on a 256MB image buffer back in the 1980s in assembly language. It was absolutely hideous. Give me a flat 32 bit memory address space any day (e.g. MC68000 around the same time.)

> 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?
Post reply on HN