Live data from Hacker News

8086 Segmented Memory was a good idea

owl.billpg.com

131–140 of 150 posts

Re: 8086 Segmented Memory was a good idea

#131

Earlier quoted context omitted.

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.

I recall turbo (Pascal I guess but I was a kid and this was 40 years ago) having options, small for all in one. Then code and data in different segments, but only one each. Then code in one but multiple data, and finally multitude of both. I probably remember the options a bit off but there is enough to state that compilers could handle segments. Though they didn't optimize it well and so the smallest option was fast…

No, that was C (and C++).

Turbo Pascal 3.x always had a single code segment, a single data segment, a single stack segment + a heap. Heap allocations were paragraph aligned (ofs=0). All pointers were far pointers.

Turbo Pascal 4.0 and up had one code segment per module (that they called units). It still had a single data segment and a single stack segment + a heap. Heap allocations were still paragraph aligned and all pointers were still far pointers.

Turbo/Borland Pascal 7.0 also supported 16-bit protected mode. I don't know if heap allocations had ofs=0 there.

None of them had "huge" arrays/pointers where pointers can point to things bigger than 64K -- at the cost of a lot of instructions for pointer arithmetic and array indexing.

Re: 8086 Segmented Memory was a good idea

#132
post #92

Earlier quoted context omitted.

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.

I remember that at some point compiler ads would brag that the new "Microland" compiler could do "segment pointers" where only the segment was stored. I don't remember when it was, but it was fairly late in the DOS era.

In retrospect, they seem so useful and obvious but apparently not. I guess the type of person who thinks near/far/huge is extremely complicated found segment pointers even more complicated.

Re: 8086 Segmented Memory was a good idea

#133
post #89

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"?

Personally I would prefer if you write it without AI help. Even with your human errors.

Re: 8086 Segmented Memory was a good idea

#134

Earlier quoted context omitted.

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

Lots of 8086 code was written that way. You’d use the segment register on paragraph alignment and basically take advantage of the This code was a nightmare to port to protected mode 80286 so it went away by the Windows 3.1 era.

I went from a 6809-based Color Computer 3 circa 1987 to a 80286. I am kicking myself today because my Uncle Bob told me the job that paid me $1,200 to get a new machine created upwards of $60,000 of value so I could have asked for enough to get a 386!

I was told not to waste any time with 80286 protected mode by all the experts I talked to. I can't complain a lot because that 80286 was crazy fast. Fast enough that when I got another job to develop some software for a teacher at my school I was able to run a Z80 emulator to develop for CP/M and get performance several times better than any real Z80!

I loved programming it too, the 286 had some 16-bit data paths that the 8086 didn't have which I took advantage of in assembly and in copy/move/zero routines that I used with Turbo Pascal which I thought was a much nicer language to C but when I got to college I switched to C because it was portable to the Sun 68k and later SPARC machines we had.

Re: 8086 Segmented Memory was a good idea

#135

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

still worth it because otherwise you have essentially no software advantage over competing architectures (at the time, mainly Motorola 6800 successors and the PDP-11 architecture)

Re: 8086 Segmented Memory was a good idea

#136
post #54

Earlier quoted context omitted.

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.

And 32-bit Windows has this kind of banking when 4GB* per app isn't enough:

https://en.wikipedia.org/wiki/Address_Windowing_Extensions

*: not actually 4GB, because that makes the kernel code harder to write and tends to lead to bad performance and lots of bugs. They could get 2GB max with the default settings and 3GB with a special configuration.

https://devblogs.microsoft.com/oldnewthing/20040812-00/?p=38...

Re: 8086 Segmented Memory was a good idea

#137
post #63
post #36

Earlier quoted context omitted.

Not entirely self-evidently. Position independent code was slower at the time and avoiding having to patching function addresses at load time is a net win. More importantly, there’s backwards compatibility. By the time the 8086 came out, people had spent serious money on getting binary-only software (WordStar cost hundreds of dollars, for example). “Buy this computer, and you can keep running the software you paid fo…

I wonder why couldn't Intel simply introduce single 'offset' register for apps ported from 8080, and make all other registers 20-24bit. Why bother with 4 different registers and all that segmentation nightmare?

A single one would require a ported app to understand that it worked with bigger registers in order to take advantage of the bigger address space. Some really old computers did work like that, but to allow several apps to coexist in memory, not to give each app more addressable memory.

The segment register solution does both almost for free in most cases. Code gets a segment, data gets a segment, stack gets a segment... and you are free to use all of memory if you bother to use the ES register. In many cases, that could be isolated to a small piece of the program so that was also quite cheap.

As someone who wrote code in assembler, Pascal, and C for those machines: it wasn't at all a nightmare. It was quite easy and simple.

Re: 8086 Segmented Memory was a good idea

#138
post #97

Earlier quoted context omitted.

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

Just sweat more blood.

Re: 8086 Segmented Memory was a good idea

#139
post #64

Earlier quoted context omitted.

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

I was under the impression that the permissions only kicked in once you were in 32-bit mode on the 386, what Windows called "386 Enhanced" mode.

Any protected mode (if enabled). It was introduced with the 286.

The operating system/DOS extender could choose to let tasks (programs) run with the highest privileges, which would turn off some of the checks but not all of them -- you still needed valid selectors into valid slots in the descriptor tables.

Re: 8086 Segmented Memory was a good idea

#140
post #67
post #62

> Need more than 64KB? Allocate two blocks. How is that compatible with an array and a simple implementation of the index operator?

It isn't. This was a problem.

You can do the equivalent of the hypothetical ADSC instruction I mentioned in another post using normal instructions. It's just that you need an uncomfortable amount.
Post reply on HN