7 ms·

8086 Segmented Memory was a good idea

71 points by billpg 3mo ago

raverbashing 3mo ago
No No, it wasn't It's the "great idea" that sounds great 5 min in and horrible 10min afterwards You know, kinda like using null as a string end character But more importantly it kept the x86 world for too long in that dead end that was 8086 mode programming "Oh if developers would just..." They won't. They haven't. And they will not ever. In hindsight maybe a binary level translator from 8080 to 8086 would have worked better (and be simple enough)
- billpg 3mo ago
  Indeed, I say as much at the end. But what should Intel have done? They needed a CPU that can run 8080 code but with more memory. Also it's the year ~1980 and we're limited to the technology of the age. A system with 64k sized windows seems unavoidable. If you extend the size of the address registers, 8080 code will only run in the first 64k, or require some kind of current window register. An 8080 mode might have worked but that would have been expensive.
  - flohofwoe 3mo ago
    > Also it's the year ~1980 and we're limited to the technology of the age. Tbf the Motorola 68000 which was released around the same time (1979) had a proper linear address space with 32-bit address registers (of which 24 bits were wired up). Also the 8086 was intended as a cheap and temporary stop gap until Intel's "proper" 32-bit CPU architecture was ready for prime time (the doomed iAPX 432).
    - smallstepforman 3mo ago
      New platforms were 68000, old platforms with legacy code just wanted access to more memory, so 8086 segments allowed 64kb chunks. A hack only usable by folks that still wanted to run their old 64kb programs. It would be a piece of trivia today if motorola were not 6 months late which forced IBM in frustration to change tracks to Intel and MS DOS instead (which worked on 8086). That 6 month drlay created WinTel of today.
    - nwallin 3mo ago
      The Motorola 68000 was roughly an order of magnitude more expensive than the Intel 8086.
- torusle 3mo ago
  > In hindsight maybe a binary level translator from 8080 to 8086 would have worked better (and be simple enough) Many programs written in assembly language used self modifying code back then. It saved RAM and improved performance. All programs that used such trickery would have broken by a binary translator.
- flohofwoe 3mo ago
  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 64 KBytes, except that the memory mapping hardware was implemented outside the CPU.
  - amiga386 3mo ago
    > 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 registers exist to think they're still running on an 8-bit Z80. What a waste of potential. The 68000 didn't pretend to be a 6502. The 80286 introduced protected mode with "segment descriptors", but this is well after MMUs existed on other CPUs, it didn't invent virtual memory. Only the 80386 offered a 32-bit flat memory model. If you want to see something to make you weep, look at the MS-DOS version of unzip. It has to do all kinds of crazy, just to allocate 64KB of RAM and get all 64KB, not 8 bytes less. And it's still locked into a memory access model that will not let it ever address more than 64KB of any one object. It's why MS-DOS was viewed as a toy OS for a toy computer. #if defined(__TURBOC__) && !defined(OS2) #include <alloc.h> /* Turbo C malloc() does not allow dynamic allocation of 64K bytes * and farmalloc(64K) returns a pointer with an offset of 8, so we * must fix the pointer. Warning: the pointer must be put back to its * original form in order to free it, use zcfree(). */ ... static ptr_table table[MAX_PTR]; /* This table is used to remember the original form of pointers * to large buffers (64K). Such pointers are normalized with a zero offset. * Since MSDOS is not a preemptive multitasking OS, this table is not * protected from concurrent access. This hack doesn't work anyway on * a protected system like OS/2. Use Microsoft C instead. */
    - rep_lodsb 3mo ago
- mschaef 3mo ago
  The 8086 was a stopgap measure to accommodate the fact the iAPX432 was in the middle of turning into the disaster it did. Given the engineering resources and timelines involved in the 8086, it wasn't a bad compromise approach. > But more importantly it kept the x86 world for too long in that dead end that was 8086 mode programming > > "Oh if developers would just..." They won't. They haven't. And they will not ever. 8086 real mode programming in the mainstream lasted from 1981 until 1991 or so. The last 35 years have 32-bit (and later 64-bit) flat model addressing with pages for the most part. Seems like a reasonable transition period, really. > In hindsight maybe a binary level translator from 8080 to 8086 would have worked better (and be simple enough) Part of the reason they liked the segmented model is that it was possible to set the segments to the same value and then ignore them entirely. That gave a programming model for the 8086 that was sufficiently close to the 8080 that it was possible to use a sort of cross assembler to do something like what you suggest. You could then opt into 8086 specific instructions and segmentation as you needed. (Which took a few years... the first IBM PC's shipped with as little as 16K of RAM.)
- wewewedxfgdf 3mo ago
  Don't know why you're being voted down - you're correct - segmented memory was an awful nasty complex way to program and the industry was eager to see the backside of it. Why would someone be popping up in 2026 saying it was awesome? Weird.
  - peterfirefly 3mo ago
    It was awesome in the sense that it was a really, really good solution to the problem they had when the 8086 was being designed: * we want to stay 16-bit * we want to make porting extremely easy * we want to make gradual upgrading of people's programs to >64K easy * we want to work well with really small memories (so don't force people to use fat pointers all the time) * we don't want the typical (or max non-redundant) instruction to get too long * we don't want an MMU * we don't want complicated bank switching * we don't want long carry chains for all address generations * -- but we still want a gigantic address space (for the time it was designed)!
tliltocatl 3mo ago
It might have worked better if x86 had general-purpose registers where every register could work as a segment. Or maybe just many more segment registers. But with only two data segment registers to play with and quite cubersome (and slow!) loads, most software just chose not to bother.
musicale 3mo ago
Google's native client (NaCl) even used it on 32-bit x86... Segmented memory (on hardware that supported segment permissions) was used to good effect in Multics as well.
- gpderetta 3mo ago
  x86 32 bit protected mode segments were a very different beast.
  - musicale 3mo ago
    I miss them.
justincormack 3mo ago
Wasm with multiple linear memories is basically segmented memory. Its a great security model.
- PunchyHamster 3mo ago
  It made fundamental mistake of starting as 32 bit memory model
  - actionfromafar 3mo ago
    It puts some drag on bloat, I quite like it.
  - justincormack 3mo ago
    You can use multiple segments (now, you couldnt originally)
  - trollbridge 3mo ago
    God help us all when a webpage needs > 4GB.
    - tlb 3mo ago
      Some of mine do. They use WASM64 with threads to run robotics simulations.
      - trollbridge 3mo ago
        That’s an “acceptable” use.
hexmiles 3mo ago
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 consoles.
- flohofwoe 3mo ago
  It's pretty much the same thing, except that all the memory mapping logic has moved from 'custom memory mapping hardware' into the CPU.
  - rzzzt 3mo ago
    Banking also appeared on the platform in the form of EMS.
    - peterfirefly 3mo ago
      And 32-bit Windows has this kind of banking when 4GB* per app isn't enough: https://en.wikipedia.org/wiki/Address_Windowing_Extensions 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=38183 https://devblogs.microsoft.com/oldnewthing/20040812-00/?p=38...
- Someone 3mo ago
  > and while banking could be annoying, I never saw it as a particularly difficult model to follow and use Segments aren’t conceptually difficult, either, but definitely could be annoying, and certainly were, if you had to access data structures larger than 64 kB. As to the differences: - you had four segment registers that you could ‘point’ anywhere, allowing you to access four 64kB regions of memory without changing them (the equivalent of bank switching) (one always was used for accessing the instruction to run, one for accessing the stack, but you could use those for other purposes, too (Could, not SHould) - segments can overlap. You could set DS and ES to the same value, for example. Segments also can be moved at 16-byte granularity. If you wanted, you could have DS address address memory range 0x0000 ≤ x < 0xFFFF and SS address memory range 0x0010 ≤ x < 0x1000F.
st_goliath 3mo ago
> 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 knows when it's fetching an instruction vs when it's fetching data, you can have two sliding windows: code (CS) and data (DS). Split them apart, and it's not much different than a Harvard-style machine and gives you access to more than 64k at a time. Still need more? No problem, the CPU has a hardware stack with dedicated push/pop/call/ret instructions and a base pointer for stack indexing. It knows when it's accessing the stack, so we can split the data window into regular data (DS) and stack data (SS). Oh, you occasionally want to copy stuff between segments or somewhere else in memory? Well, to encode 3 segments we need 2 bits anyway, let's throw in an extra data window (ES) and some DS-to-ES copy instructions.
- gdwatson 3mo ago
  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.
  - rob74 3mo ago
    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...
    - bluGill 3mo ago
      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.
AKSF_Ackermann 3mo ago
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.
- rep_lodsb 3mo ago
  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).
  - AKSF_Ackermann 3mo ago
    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.
- billpg 3mo ago
  Why would you ever want a single 64k object? That's like an entire machine's worth of memory!
- carry_bit 3mo ago
  It's basically a 16-bit machine with PAE; 32-bit with PAE runs into similar issues if you want an object larger than 4GB.
senfiaj 3mo ago
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.
- flohofwoe 3mo ago
  > 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).
  - senfiaj 3mo ago
    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.
    - mschaef 3mo ago
      There is no such thing as a "2MB program".... all you have is a program composed of <=64K segments, which are easy enough to fit into the hole. 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.
      - PunchyHamster 3mo ago
        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
wewewedxfgdf 3mo ago
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.
- PaulHoule 3mo ago
  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.
  - trollbridge 3mo ago
    Lots of 8086 code was written that way. You’d use the segment register on paragraph alignment and basically take advantage of the << 4 + logic. This code was a nightmare to port to protected mode 80286 so it went away by the Windows 3.1 era.
    - PaulHoule 3mo ago
      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.
b800h 3mo ago
I quite enjoyed using the memory segments - I thought they were quite intuitive and helped in reasoning about the machine.
RagnarD 3mo ago
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.)
- mschaef 3mo ago
  > 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 else) license to get to that 32-bit address space. (If you weren't doing it all in memory, then you're having to depending on paging stuff out to disk, implying you either have a real OS or a flat memory model isn't enough to save you since you're manually having to page stuff to disk and back anyway.) That's a super strange scenario you're describing.
  - porridgeraisin 3mo ago
    Perhaps they meant KB?
    - mschaef 3mo ago
      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.)
    - RagnarD 3mo ago
      Yes, mental typo. 256KB.
  - sumtechguy 3mo ago
    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 memory is right 1MB of memory in the early 90s was like 200-300 per meg. Would have to dig up a computer shopper and look.
PunchyHamster 3mo ago
Author comes from some weird assumption that software is some annoying byproduct of making hardware, rather than a fact that the hardware is made to run software and making it easier is a goal. It was just a hack. Hack to delay migration to 32 bit architecture. Effective one, but hack nonetheless
- NoGravitas 3mo ago
  I think it's more like marking a transition in how we thought about software. When I was learning C, we did things at a reasonably low level. I was learning data structures, and building things like binary trees out of things like structs, and the structs were fixed-sized memory blocks holding pointers to regions of memory which were either more structs or data fields. All reasonable stuff. But we weren't writing for a particular machine. We were writing for the idea of a machine, and part of that idea was that the machine had a flat memory model. This really struck me when I compiled my homework (parse some data into a tree) on the departmental SunOS server, and it worked fine, and then took it home and compiled it with Borland C for DOS on my 386 and it segfaulted on the same data. That was when I learned to hate segmented memory, but looking back, it seems to me that I learned the wrong lesson. I learned to write software for a lowish-level model of an idealized computer. The generation before me was always writing software for a specific computer, consisting of a specific set of hardware. The software was always the goal, but the nature of the task was defined by the hardware. Things like memory segmentation were facts about the hardware, and the available hardware varied widely at the time in a way modern hardware doesn't, really, except maybe in the embedded space.
peterfirefly 3mo ago
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.
- peterfirefly 3mo ago
  btw, we only really need ADSC for the ES register.
j16sdiz 3mo ago
> 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.
deepsummer 3mo ago
1992-me hates the author. Coming from 68k assembly, x86 was a nightmare. And together with the ridiculous number of registers, segments made up a huge chunk of that horrible experience.
- billpg 3mo ago
  1992-author (me) is wondering if he'll ever get a girlfriend. (And I completely agree.)
- projektfu 3mo ago
  What? It has 4 times as many general purpose registers as you'd ever need, right? /s
  - deftio 3mo ago
    Agree.. 68k assembly was dreamy compared to 80x86..
    - BearOso 3mo ago
      He's referring to accumulator styles, eg. the 6502.
- forinti 3mo ago
  I knew a bit of 6502 assembly, so I was happy just to have more RAM and more registers. Looking back, the simplicity of the instruction set seems quaint next to the thousands of instructions we have today.
pif 3mo ago
> Need more than 64KB? Allocate two blocks. How is that compatible with an array and a simple implementation of the index operator?
- pjc50 3mo ago
  It isn't. This was a problem.
  - trollbridge 3mo ago
    Not really. Compilers had huge pointers. They just were slower since they had to do 32 bit math.
  - peterfirefly 3mo ago
    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.
- billpg 3mo ago
  I once developed for PC-GEOS, which wanted all memory in exactly 8K sized blocks. I wrote a set of C macros that presented an array-of-arrays as a single collection by using mod/divide operations on the index.
waynecochran 3mo ago
I blame 8086 segmented memory and the rest of its horrid architecture on why no one liked programming in assembly language. There were other elegant RISC machines with flat memory models and large general register sets that were a complete joy to program. Memory paging allowed you to do everything you needed to do that segmented memory provided and left the programmer unbothered for the most part.
- deftio 3mo ago
  Totally agree.
noitemtoshow 3mo ago
Nope. It was bad. It made computers in the 286/386 eras having RAM above 1MB sitting there and doing nothing. It took years to transit to DOS/4G and then finally 32bit OS Windows 95.
- chasil 3mo ago
  Ah, memories. https://en.wikipedia.org/wiki/Expanded_memory https://en.wikipedia.org/wiki/Expanded_memory https://en.wikipedia.org/wiki/Extended_memory https://en.wikipedia.org/wiki/Extended_memory https://en.wikipedia.org/wiki/Physical_Address_Extension https://en.wikipedia.org/wiki/Physical_Address_Extension
deftio 3mo ago
Wow.... I remember writing 8086 assembly on MASM and another assembler I've forgotten the name of, and then also doing inline ASM in Turbo C++ The segment thing and the convoluted different pointer math caused real gymnastics if you ever had data bigger than 64k... such as images. I always thought of the segments as windows of 64k but moving between those windows, esp with the limited register set, required some real mental gymnastics.
- trollbridge 3mo ago
  Contemporary hardware rarely had images over 64k and memory bandwidth at the time made them a laughable concept.
trollbridge 3mo ago
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 rarely executed code existed on either end. In addition data could be its own segment, and/or memory mapped I/O outside of the 128K space. But memory got so cheap that nobody bothered with this, and the performance gains of writing code that way wasn’t worth the effort. X86 code was compact enough most programs could cram their code into 64k anyway, or 64k per functional unit with calls between them being rare. The real tragedy is they went for 20 bit instead of 24 bit. 8086 with 16MB of addressable space would have been a very different world and would have made little difference if there use. (Paragraphs would have been 256 bytes, the same size as a page; most data structures would have been fine with that.)
- billpg 3mo ago
  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"?
  - chowells 3mo ago
    "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.
M95D 3mo ago
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 4GB. And wouldn't it be nice if 386 had 64KB pages (1 segment)?
- bonzini 3mo ago
  That wouldn't have worked, the point was to pack data in memory. Even on 64kb computers, MS-DOS 1.x loaded .COM files at the bottom of available memory and allowed using the "familiar" CALL 5 interface even if the program was not loaded at physical address 0x100 (which is part of the interrupt table on x86). MS-DOS 2.x augmented that with TSR (terminate and stay resident) programs that could relocate themselves to use the minimal amount of memory at 16-byte offsets. The 68000 was a complete break so it opted for relocatable code (which also needed more registers, and in fact the 68k had 16 instead of 8).
- billpg 3mo ago
  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.
richard_todd 3mo ago
The author assumes the way to keep segments going with larger memory would have been to change the amount of overlap, but it would have also been possible to make an 80286 where the segment registers were > 16bits, and everything else is 16 bits like before. Now you have extra segments that are still paragraphs apart and existing software could still function (you'd need new instruction variants to move data into and out of the enlarged portion of the segment registers.. call them ECS, EDS, or whatever). Anyway, just a thought.
draginol 3mo ago
Eh. I don't think "developers broke it". The 8086 gave us something like a flat 20-bit address space and then encoded it as a segment. Once that exists, normalizing far pointers is inevitable. Not to do a "The Amiga was ahead of its time" thing but as a reminder, 68000 has a flat 24-bit address.

71 points by billpg 3mo ago

No No, it wasn't It's the "great idea" that sounds great 5 min in and horrible 10min afterwards You know, kinda like using null as a string end character But more importantly it kept the x86 world for too long in that dead end that was 8086 mode programming "Oh if developers would just..." They won't. They haven't. And they will not ever. In hindsight maybe a binary level translator from 8080 to 8086 would have worked better (and be simple enough)

billpg 3mo ago
Indeed, I say as much at the end. But what should Intel have done? They needed a CPU that can run 8080 code but with more memory. Also it's the year ~1980 and we're limited to the technology of the age. A system with 64k sized windows seems unavoidable. If you extend the size of the address registers, 8080 code will only run in the first 64k, or require some kind of current window register. An 8080 mode might have worked but that would have been expensive.
- flohofwoe 3mo ago
  > Also it's the year ~1980 and we're limited to the technology of the age. Tbf the Motorola 68000 which was released around the same time (1979) had a proper linear address space with 32-bit address registers (of which 24 bits were wired up). Also the 8086 was intended as a cheap and temporary stop gap until Intel's "proper" 32-bit CPU architecture was ready for prime time (the doomed iAPX 432).
  - smallstepforman 3mo ago
    New platforms were 68000, old platforms with legacy code just wanted access to more memory, so 8086 segments allowed 64kb chunks. A hack only usable by folks that still wanted to run their old 64kb programs. It would be a piece of trivia today if motorola were not 6 months late which forced IBM in frustration to change tracks to Intel and MS DOS instead (which worked on 8086). That 6 month drlay created WinTel of today.
  - nwallin 3mo ago
    The Motorola 68000 was roughly an order of magnitude more expensive than the Intel 8086.
torusle 3mo ago
> In hindsight maybe a binary level translator from 8080 to 8086 would have worked better (and be simple enough) Many programs written in assembly language used self modifying code back then. It saved RAM and improved performance. All programs that used such trickery would have broken by a binary translator.
flohofwoe 3mo ago
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 64 KBytes, except that the memory mapping hardware was implemented outside the CPU.
- amiga386 3mo ago
  > 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 registers exist to think they're still running on an 8-bit Z80. What a waste of potential. The 68000 didn't pretend to be a 6502. The 80286 introduced protected mode with "segment descriptors", but this is well after MMUs existed on other CPUs, it didn't invent virtual memory. Only the 80386 offered a 32-bit flat memory model. If you want to see something to make you weep, look at the MS-DOS version of unzip. It has to do all kinds of crazy, just to allocate 64KB of RAM and get all 64KB, not 8 bytes less. And it's still locked into a memory access model that will not let it ever address more than 64KB of any one object. It's why MS-DOS was viewed as a toy OS for a toy computer. #if defined(__TURBOC__) && !defined(OS2) #include <alloc.h> /* Turbo C malloc() does not allow dynamic allocation of 64K bytes * and farmalloc(64K) returns a pointer with an offset of 8, so we * must fix the pointer. Warning: the pointer must be put back to its * original form in order to free it, use zcfree(). */ ... static ptr_table table[MAX_PTR]; /* This table is used to remember the original form of pointers * to large buffers (64K). Such pointers are normalized with a zero offset. * Since MSDOS is not a preemptive multitasking OS, this table is not * protected from concurrent access. This hack doesn't work anyway on * a protected system like OS/2. Use Microsoft C instead. */
  - rep_lodsb 3mo ago
mschaef 3mo ago
The 8086 was a stopgap measure to accommodate the fact the iAPX432 was in the middle of turning into the disaster it did. Given the engineering resources and timelines involved in the 8086, it wasn't a bad compromise approach. > But more importantly it kept the x86 world for too long in that dead end that was 8086 mode programming > > "Oh if developers would just..." They won't. They haven't. And they will not ever. 8086 real mode programming in the mainstream lasted from 1981 until 1991 or so. The last 35 years have 32-bit (and later 64-bit) flat model addressing with pages for the most part. Seems like a reasonable transition period, really. > In hindsight maybe a binary level translator from 8080 to 8086 would have worked better (and be simple enough) Part of the reason they liked the segmented model is that it was possible to set the segments to the same value and then ignore them entirely. That gave a programming model for the 8086 that was sufficiently close to the 8080 that it was possible to use a sort of cross assembler to do something like what you suggest. You could then opt into 8086 specific instructions and segmentation as you needed. (Which took a few years... the first IBM PC's shipped with as little as 16K of RAM.)
wewewedxfgdf 3mo ago
Don't know why you're being voted down - you're correct - segmented memory was an awful nasty complex way to program and the industry was eager to see the backside of it. Why would someone be popping up in 2026 saying it was awesome? Weird.
- peterfirefly 3mo ago
  It was awesome in the sense that it was a really, really good solution to the problem they had when the 8086 was being designed: * we want to stay 16-bit * we want to make porting extremely easy * we want to make gradual upgrading of people's programs to >64K easy * we want to work well with really small memories (so don't force people to use fat pointers all the time) * we don't want the typical (or max non-redundant) instruction to get too long * we don't want an MMU * we don't want complicated bank switching * we don't want long carry chains for all address generations * -- but we still want a gigantic address space (for the time it was designed)!

tliltocatl 3mo ago

It might have worked better if x86 had general-purpose registers where every register could work as a segment. Or maybe just many more segment registers. But with only two data segment registers to play with and quite cubersome (and slow!) loads, most software just chose not to bother.

musicale 3mo ago

Google's native client (NaCl) even used it on 32-bit x86... Segmented memory (on hardware that supported segment permissions) was used to good effect in Multics as well.

gpderetta 3mo ago
x86 32 bit protected mode segments were a very different beast.
- musicale 3mo ago
  I miss them.

justincormack 3mo ago

Wasm with multiple linear memories is basically segmented memory. Its a great security model.

PunchyHamster 3mo ago
It made fundamental mistake of starting as 32 bit memory model
- actionfromafar 3mo ago
  It puts some drag on bloat, I quite like it.
- justincormack 3mo ago
  You can use multiple segments (now, you couldnt originally)
- trollbridge 3mo ago
  God help us all when a webpage needs > 4GB.
  - tlb 3mo ago
    Some of mine do. They use WASM64 with threads to run robotics simulations.
    - trollbridge 3mo ago
      That’s an “acceptable” use.

hexmiles 3mo ago

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

flohofwoe 3mo ago
It's pretty much the same thing, except that all the memory mapping logic has moved from 'custom memory mapping hardware' into the CPU.
- rzzzt 3mo ago
  Banking also appeared on the platform in the form of EMS.
  - peterfirefly 3mo ago
    And 32-bit Windows has this kind of banking when 4GB* per app isn't enough: https://en.wikipedia.org/wiki/Address_Windowing_Extensions 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=38183 https://devblogs.microsoft.com/oldnewthing/20040812-00/?p=38...
Someone 3mo ago
> and while banking could be annoying, I never saw it as a particularly difficult model to follow and use Segments aren’t conceptually difficult, either, but definitely could be annoying, and certainly were, if you had to access data structures larger than 64 kB. As to the differences: - you had four segment registers that you could ‘point’ anywhere, allowing you to access four 64kB regions of memory without changing them (the equivalent of bank switching) (one always was used for accessing the instruction to run, one for accessing the stack, but you could use those for other purposes, too (Could, not SHould) - segments can overlap. You could set DS and ES to the same value, for example. Segments also can be moved at 16-byte granularity. If you wanted, you could have DS address address memory range 0x0000 ≤ x < 0xFFFF and SS address memory range 0x0010 ≤ x < 0x1000F.

st_goliath 3mo ago

> 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 knows when it's fetching an instruction vs when it's fetching data, you can have two sliding windows: code (CS) and data (DS). Split them apart, and it's not much different than a Harvard-style machine and gives you access to more than 64k at a time. Still need more? No problem, the CPU has a hardware stack with dedicated push/pop/call/ret instructions and a base pointer for stack indexing. It knows when it's accessing the stack, so we can split the data window into regular data (DS) and stack data (SS). Oh, you occasionally want to copy stuff between segments or somewhere else in memory? Well, to encode 3 segments we need 2 bits anyway, let's throw in an extra data window (ES) and some DS-to-ES copy instructions.

gdwatson 3mo ago
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.
- rob74 3mo ago
  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...
  - bluGill 3mo ago
    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.

AKSF_Ackermann 3mo ago

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.

rep_lodsb 3mo ago
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).
- AKSF_Ackermann 3mo ago
  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.
billpg 3mo ago
Why would you ever want a single 64k object? That's like an entire machine's worth of memory!
carry_bit 3mo ago
It's basically a 16-bit machine with PAE; 32-bit with PAE runs into similar issues if you want an object larger than 4GB.

senfiaj 3mo ago

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.

flohofwoe 3mo ago
> 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).
- senfiaj 3mo ago
  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.
  - mschaef 3mo ago
    There is no such thing as a "2MB program".... all you have is a program composed of <=64K segments, which are easy enough to fit into the hole. 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.
    - PunchyHamster 3mo ago
      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

wewewedxfgdf 3mo ago

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.

PaulHoule 3mo ago
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.
- trollbridge 3mo ago
  Lots of 8086 code was written that way. You’d use the segment register on paragraph alignment and basically take advantage of the << 4 + logic. This code was a nightmare to port to protected mode 80286 so it went away by the Windows 3.1 era.
  - PaulHoule 3mo ago
    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.

b800h 3mo ago

I quite enjoyed using the memory segments - I thought they were quite intuitive and helped in reasoning about the machine.

RagnarD 3mo ago

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

mschaef 3mo ago
> 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 else) license to get to that 32-bit address space. (If you weren't doing it all in memory, then you're having to depending on paging stuff out to disk, implying you either have a real OS or a flat memory model isn't enough to save you since you're manually having to page stuff to disk and back anyway.) That's a super strange scenario you're describing.
- porridgeraisin 3mo ago
  Perhaps they meant KB?
  - mschaef 3mo ago
    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.)
  - RagnarD 3mo ago
    Yes, mental typo. 256KB.
- sumtechguy 3mo ago
  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 memory is right 1MB of memory in the early 90s was like 200-300 per meg. Would have to dig up a computer shopper and look.

PunchyHamster 3mo ago

Author comes from some weird assumption that software is some annoying byproduct of making hardware, rather than a fact that the hardware is made to run software and making it easier is a goal. It was just a hack. Hack to delay migration to 32 bit architecture. Effective one, but hack nonetheless

NoGravitas 3mo ago
I think it's more like marking a transition in how we thought about software. When I was learning C, we did things at a reasonably low level. I was learning data structures, and building things like binary trees out of things like structs, and the structs were fixed-sized memory blocks holding pointers to regions of memory which were either more structs or data fields. All reasonable stuff. But we weren't writing for a particular machine. We were writing for the idea of a machine, and part of that idea was that the machine had a flat memory model. This really struck me when I compiled my homework (parse some data into a tree) on the departmental SunOS server, and it worked fine, and then took it home and compiled it with Borland C for DOS on my 386 and it segfaulted on the same data. That was when I learned to hate segmented memory, but looking back, it seems to me that I learned the wrong lesson. I learned to write software for a lowish-level model of an idealized computer. The generation before me was always writing software for a specific computer, consisting of a specific set of hardware. The software was always the goal, but the nature of the task was defined by the hardware. Things like memory segmentation were facts about the hardware, and the available hardware varied widely at the time in a way modern hardware doesn't, really, except maybe in the embedded space.

peterfirefly 3mo ago

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.

peterfirefly 3mo ago
btw, we only really need ADSC for the ES register.

j16sdiz 3mo ago

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

deepsummer 3mo ago

1992-me hates the author. Coming from 68k assembly, x86 was a nightmare. And together with the ridiculous number of registers, segments made up a huge chunk of that horrible experience.

billpg 3mo ago
1992-author (me) is wondering if he'll ever get a girlfriend. (And I completely agree.)
projektfu 3mo ago
What? It has 4 times as many general purpose registers as you'd ever need, right? /s
- deftio 3mo ago
  Agree.. 68k assembly was dreamy compared to 80x86..
  - BearOso 3mo ago
    He's referring to accumulator styles, eg. the 6502.
forinti 3mo ago
I knew a bit of 6502 assembly, so I was happy just to have more RAM and more registers. Looking back, the simplicity of the instruction set seems quaint next to the thousands of instructions we have today.

pif 3mo ago

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

pjc50 3mo ago
It isn't. This was a problem.
- trollbridge 3mo ago
  Not really. Compilers had huge pointers. They just were slower since they had to do 32 bit math.
- peterfirefly 3mo ago
  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.
billpg 3mo ago
I once developed for PC-GEOS, which wanted all memory in exactly 8K sized blocks. I wrote a set of C macros that presented an array-of-arrays as a single collection by using mod/divide operations on the index.

waynecochran 3mo ago

I blame 8086 segmented memory and the rest of its horrid architecture on why no one liked programming in assembly language. There were other elegant RISC machines with flat memory models and large general register sets that were a complete joy to program. Memory paging allowed you to do everything you needed to do that segmented memory provided and left the programmer unbothered for the most part.

deftio 3mo ago
Totally agree.

noitemtoshow 3mo ago

Nope. It was bad. It made computers in the 286/386 eras having RAM above 1MB sitting there and doing nothing. It took years to transit to DOS/4G and then finally 32bit OS Windows 95.

chasil 3mo ago
Ah, memories. https://en.wikipedia.org/wiki/Expanded_memory https://en.wikipedia.org/wiki/Expanded_memory https://en.wikipedia.org/wiki/Extended_memory https://en.wikipedia.org/wiki/Extended_memory https://en.wikipedia.org/wiki/Physical_Address_Extension https://en.wikipedia.org/wiki/Physical_Address_Extension

deftio 3mo ago

Wow.... I remember writing 8086 assembly on MASM and another assembler I've forgotten the name of, and then also doing inline ASM in Turbo C++ The segment thing and the convoluted different pointer math caused real gymnastics if you ever had data bigger than 64k... such as images. I always thought of the segments as windows of 64k but moving between those windows, esp with the limited register set, required some real mental gymnastics.

trollbridge 3mo ago
Contemporary hardware rarely had images over 64k and memory bandwidth at the time made them a laughable concept.

trollbridge 3mo ago

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 rarely executed code existed on either end. In addition data could be its own segment, and/or memory mapped I/O outside of the 128K space. But memory got so cheap that nobody bothered with this, and the performance gains of writing code that way wasn’t worth the effort. X86 code was compact enough most programs could cram their code into 64k anyway, or 64k per functional unit with calls between them being rare. The real tragedy is they went for 20 bit instead of 24 bit. 8086 with 16MB of addressable space would have been a very different world and would have made little difference if there use. (Paragraphs would have been 256 bytes, the same size as a page; most data structures would have been fine with that.)

billpg 3mo ago
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"?
- chowells 3mo ago
  "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.

M95D 3mo ago

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 4GB. And wouldn't it be nice if 386 had 64KB pages (1 segment)?

bonzini 3mo ago
That wouldn't have worked, the point was to pack data in memory. Even on 64kb computers, MS-DOS 1.x loaded .COM files at the bottom of available memory and allowed using the "familiar" CALL 5 interface even if the program was not loaded at physical address 0x100 (which is part of the interrupt table on x86). MS-DOS 2.x augmented that with TSR (terminate and stay resident) programs that could relocate themselves to use the minimal amount of memory at 16-byte offsets. The 68000 was a complete break so it opted for relocatable code (which also needed more registers, and in fact the 68k had 16 instead of 8).
billpg 3mo ago
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.

richard_todd 3mo ago

The author assumes the way to keep segments going with larger memory would have been to change the amount of overlap, but it would have also been possible to make an 80286 where the segment registers were > 16bits, and everything else is 16 bits like before. Now you have extra segments that are still paragraphs apart and existing software could still function (you'd need new instruction variants to move data into and out of the enlarged portion of the segment registers.. call them ECS, EDS, or whatever). Anyway, just a thought.

draginol 3mo ago

Eh. I don't think "developers broke it". The 8086 gave us something like a flat 20-bit address space and then encoded it as a segment. Once that exists, normalizing far pointers is inevitable. Not to do a "The Amiga was ahead of its time" thing but as a reminder, 68000 has a flat 24-bit address.