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

91–100 of 150 posts

Re: 8086 Segmented Memory was a good idea

#91

Post by billpg »

M95D wrote: post #88

They could have used 16 bit segments with no overlap. It would have a 16 bit offset register + a 16 bit segment selector register with the top 12 bits reserved (always 0). 16 bit software would run as usual in a single segment, while larger programs would use both registers for 20 bit addresses. 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…

I kinda wish they had. 64k windows with no overlap would make segment registers a slightly inconvenient 32-bit address register.

I get why hey didn't. Someone might want to run two processes each with its own segment, but the whole machine might only have 64k in total.

Re: 8086 Segmented Memory was a good idea

#92

Post by bonzini »

AnimalMuppet wrote: post #72
AshamedCaptain wrote: post #59

Earlier quoted context omitted.

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

But with only four segment registers, you couldn't treat it as that - not unless you only had four objects. So treating it as a sliding window was all you actually could do with it.

With 6-7 general purpose registers you could have; since anyway only three of them were usable for addressing you constantly had to load from memory. just use MOV ES instead of MOV BX to load a pointer and you actually got to increase your GPRs by one or two. Nobody did it except for larger memory areas which were allocated using farmalloc() or the INT 21h allocator.

Re: 8086 Segmented Memory was a good idea

#93

Post by wang_li »

alerighi wrote: post #73
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.

Except than later we returned to a sort-of segmented memory. That is of course paging, our programs allocates pages of memory that are a fixed size (4096 bytes) and are arranged in memory or in swap space how the OS decides. We just have the illusion of a "flat" memory model, but it's not really flat, the CPU and the operating system does an important job in translating our flat memory model in something that is not…

Paging is not part of the CPU architecture. On CPUs of the time the MMU that brought paging to the party often was a completely separate peripheral that the CPU interacted with to gate access to RAM. By contrast segments are an integral part of the CPU instruction set and your code either has to limit itself to 64KB or your application had to be aware of and include logic to manage segments.

As an aside, the memory model is flat, it's just not physically linear when implementing virtual memory addressing.

Re: 8086 Segmented Memory was a good idea

#94

Post by mschaef »

AnimalMuppet wrote: post #79
mschaef wrote: post #55

Earlier quoted context omitted.

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

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

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

Re: 8086 Segmented Memory was a good idea

#95

Post by chowells »

billpg wrote: post #89
trollbridge wrote: post #87

Did anyone else find the AI written style of this offputting? 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 rarel…

Hi. I wrote it, and I'm a human. (Or at least I think I am.) I did use an AI for spell-checking, punctuation, generally making it flow, but its all my text. You think a machine is going to come up with "near pointers, far pointers, wherever-you-are pointers"?

"generally make it flow" is exactly the problem. It's a process of smoothing over any interesting features of the text to replace them with plastic. It's submerging the actual information you wish to convey under a layer of low-entropy noise. The whole signal may still be there, but having to find it under a uniform glossy finish is work for the reader. It's work you didn't need to delegate to the reader.

LLMs generate low-entropy text. That's their entire purpose. But good writing isn't about being as low-entropy as possible. It's about producing peaks and valleys. As a person who's been participating in human-to-human communication your entire life, you probably have a pretty well-developed sense of how to structure the flow of a piece of communication. The small arcs with their ebbs and flows of tension and density provide the reader a rough surface that gives them enough traction to easily move from point to point. Don't let an LLM smooth out all the gaps. It makes it hard for a reader to keep their footing in the text.

Re: 8086 Segmented Memory was a good idea

#96

Post by mschaef »

sumtechguy wrote: post #77
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…

Probably talking about swapping it in from some external datastore. These days you would open the file and dump it into a single buffer and rip across it, and not even really stress about it. Even 256 meg of hard drive. That would have been impressively expensive in the 80s. Back then you had to chunk it out and fiddle with the offsets. Even then you still would have had to manage loading out the next chunk. If my me…

> Even 256 meg of hard drive. That would have been impressively expensive in the 80s.

I only have a couple reference points around this scale:

My dad's company had a system set up with a searchable index of a bunch of legal testimony. It was a Compaq Deskpro 386 running Unix with an attached 1GB disk. The 1GB disk set up was as big as the machine itself.

A few years later, I worked with a Cyber mainframe equipped with around 30GB of total attached disk storage. The disk array literally filled a room.

256MB disk on an 80's PC would have definitely been quite a bit.

Re: 8086 Segmented Memory was a good idea

#97

Post by saulpw »

chowells wrote: post #95
billpg wrote: post #89

Earlier quoted context omitted.

Hi. I wrote it, and I'm a human. (Or at least I think I am.) I did use an AI for spell-checking, punctuation, generally making it flow, but its all my text. You think a machine is going to come up with "near pointers, far pointers, wherever-you-are pointers"?

"generally make it flow" is exactly the problem. It's a process of smoothing over any interesting features of the text to replace them with plastic. It's submerging the actual information you wish to convey under a layer of low-entropy noise. The whole signal may still be there, but having to find it under a uniform glossy finish is work for the reader. It's work you didn't need to delegate to the reader. LLMs genera…

> As a person who's been participating in human-to-human communication your entire life, you probably have a pretty well-developed sense of how to structure the flow of a piece of communication.

Not OP, but this is where you're wrong. The vast majority of people, myself included, have difficulty structuring communication for effectiveness to a wide audience. When I manage to pull it off I'm very proud of the work, but I can't just sit down and do it. Review with an LLM helps me find those places where it CLANKS, distracting the reader, taking them out of the flow. This is why every professional writer has an editor; good communication is quite hard.

Re: 8086 Segmented Memory was a good idea

#98

Post by simiones »

bux93 wrote: post #40
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?

Linux is only used as a kernel temporarily until GNU is finished.

You mean GNU Hurd, I guess.

Re: 8086 Segmented Memory was a good idea

#99

Post by ThrowawayR2 »

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.

Flat memory was a better idea but it wasn't a cheaper idea, and cheaper beats good. A casual Googling shows a price of $2,880 for a IBM PC in ~1982 dollars versus $8,900 for a Sun Microsystems Sun-1 with a MC68000.

Re: 8086 Segmented Memory was a good idea

#100

Post by trollbridge »

bluGill wrote: post #74
rob74 wrote: post #25

Earlier quoted context omitted.

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

I'm sure a modern compiler would have no problem with it, but in 1980 optimizer technology wasn't there yet. Modern compilers use more memory that engineers would dare dream of in 1980. By having no problem I mean we know enough about writing an optimizer to write such a thing. I don't think any compiler does, just that they could.

Compilers in 1980 generated 64k code segments and had no other memory model.

Most people wrote assembler particularly if they wanted to use more then 64k.

Most non assembly programs were interpreted oddly enough and most such interpreters were also mostly 64k.

Post reply on HN