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

21–30 of 150 posts

Re: 8086 Segmented Memory was a good idea

#21

Post by flohofwoe »

senfiaj wrote: post #16

For its time it was a decent idea. Software was smaller and simpler. But today (and even before 64-bit) software is larger, more complex, we also need memory protection / isolation and more flexible memory allocation / sharing, so paging memory was not introduced for nothing.

> we also need memory protection / isolation

I seem to remember that memory segments came with a permission system (read-only, read/write, execute) in 'protected mode'. Probably only added in the 286 though (I was always more of an m68k guy at that time).

Re: 8086 Segmented Memory was a good idea

#22

Post by rep_lodsb »

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.

A lot of that is just bloat that you wouldn't have had back then. But it could still be handled by an 8086, not by storing the raw HTML in memory at all, but parsing it as it loads. Each DOM node would be its own object with child pointers, with attributes and names all converted into binary numbers of (at most) 32 bits each.

64K of actual text content in a single node could be reached in some documents, but it's not that small, more than a chapter of a typical book.

What was always a problem for segmented memory was graphics, at least if you wanted higher resolution than 320x200 at 256 colors. But you could have a segment pointer to each row of pixels instead of an entire image, as long as it would still fit within 1 MB (16 MB in the 286 protected mode).

Re: 8086 Segmented Memory was a good idea

#23

Post by PaulHoule »

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.

Personally I enjoyed writing assembly with segments. You can have 64k of code, 64k of data and 64k of stack without trying. So long as no individual data structure is larger than 64k there is no essential difficulty working with 16 bit pointers.

When I think back I think it would be fun to have a hierarchical structure where composite data structures (think an array or hash map) are referred to with a pointer that goes into the segment register and you index inside a data structure with a regular pointer.

Re: 8086 Segmented Memory was a good idea

#24

Post by gdwatson »

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.

Re: 8086 Segmented Memory was a good idea

#25

Post by rob74 »

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.

Plus all this pointer juggling would have been more or less ok (or not ok, but doable) when programming in assembly, but for a compiler it would have been a recipe for disaster...

Re: 8086 Segmented Memory was a good idea

#26

Post by rep_lodsb »

amiga386 wrote: post #13
flohofwoe wrote: post #7

Earlier quoted context omitted.

It's not all that different from the memory pages we have today, except that the 'segment' addressing has become a lot more complex under the hood (multi-level page tables) and a lot simpler at the surface (by merging the 'segment-' and page-address bits into a single virtual address). PS: and segmented memory wasn't all that different from the memory banking used before in 8-bit home computers to address more than 6…

> It's not all that different from the memory pages we have today An MMU gives you a flat addressing model. There is no comparison. 8086 segments are rigidly locked to a 64KB window that goes forward in memory 16 bytes for every segment (so segmented address 1234:5678 is linear address $12340 + $5678 = $179B8) It didn't do this to offer a useful feature like an MMU. It did this to allow code that doesn't know segment…

That's a limitation of the Turbo C library, as the comment says. DOS memory allocation functions take the size in 16-byte "paragraphs", and return a segment, with the allocated memory starting at offset zero in that segment.

Re: 8086 Segmented Memory was a good idea

#27

Post by senfiaj »

flohofwoe wrote: post #21
senfiaj wrote: post #16

For its time it was a decent idea. Software was smaller and simpler. But today (and even before 64-bit) software is larger, more complex, we also need memory protection / isolation and more flexible memory allocation / sharing, so paging memory was not introduced for nothing.

> we also need memory protection / isolation I seem to remember that memory segments came with a permission system (read-only, read/write, execute) in 'protected mode'. Probably only added in the 286 though (I was always more of an m68k guy at that time).

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. Also, paging makes permissions and memory sharing more granular.

Re: 8086 Segmented Memory was a good idea

#28

Post by KellyCriterion »

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 won this race?

Re: 8086 Segmented Memory was a good idea

#29

Post by AKSF_Ackermann »

rep_lodsb wrote: post #22
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.

A lot of that is just bloat that you wouldn't have had back then. But it could still be handled by an 8086, not by storing the raw HTML in memory at all, but parsing it as it loads. Each DOM node would be its own object with child pointers, with attributes and names all converted into binary numbers of (at most) 32 bits each. 64K of actual text content in a single node could be reached in some documents, but it's not…

True, graphics is a better example of a period-correct >=64k work, but the point is that there are multiple things where you don't expect the data to be that big until it suddenly is.

Re: 8086 Segmented Memory was a good idea

#30

Post by wewewedxfgdf »

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…

Being technically best has long been known to not be correlated to market success in the way that makes logical sense to technical people who feel confused about this.
Post reply on HN