4 ms·

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 pr

by senfiaj 4mo 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 4mo 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 4mo 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 4mo 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 4mo 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
      - mschaef 4mo ago
        I should preface this by saying I'm taking about x86 segmentation in general. On the 8086 you're right, but the 8086 can't address 2MB of memory to begin with. On the 80286 in protected mode, the situation is different in the way I'm about to describe. The memory itself doesn't have to be contiguous. 2MB of 64K segments maps to 32 segments. So you need 32 locations in physical memory capable of storing 64K. The programming model for addressing that block of memory necessarily includes both segment selectors and offsets. The segment selectors are indices into a segment table that contains the base address of each of the 32 segments. As long as the segment selectors themselves can be allocated contiguously in the segment table, you have enough to be able to compute which segment you need for which address in the 2MB range. It's the indirection through the segments table that maps it to physical addresses that do not need to be contiguous. Raymond Chen talks a bit about how it worked in Windows 3.x here: https://devblogs.microsoft.com/oldnewthing/20171113-00/?p=97386 https://devblogs.microsoft.com/oldnewthing/20171113-00/?p=97...
        senfiaj 4mo ago
        >> 8086 can't address 2MB of memory This was just for illustration, not claiming that actual 8086 does this. >> Raymond Chen talks a bit about how it worked in Windows 3.x here: https://devblogs.microsoft.com/oldnewthing/20171113-00/?p=97 https://devblogs.microsoft.com/oldnewthing/20171113-00/?p=97... 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. Paging later made this kind of thing look like one flat array, a thing segmentation could not: making non-contiguous physical RAM appear contiguous to the program.
        mschaef 4mo ago
        > 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 bypassed if you need to for whatever reason. I'd argue that these are useful engineering abstractions that made the best of a less than ideal situation. (The reality of the world being that there are no "ideal" situations... you have to work with what you have at the moment to solve the problem you have. These days, I'd argue that a pointer into a 'flat' memory space is counter productive to the extent it hides issues around cache hierarchy, NUMA, etc. In 1986, we had to worry that a flat memory space looked discontiguous. In 2026, we have to worry the a discontiguous memory space looks flat.
- pjc50 4mo ago
  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.
  - peterfirefly 4mo ago
    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.
    - senfiaj 4mo ago
      If I'm not mistaken 286's protected mode wasn't really that popular because it breaks real mode DOS programs. Meanwhile, 386's 32-bit protected mode with paging and virtual 8086 mode was a big success.
- tliltocatl 4mo ago
  Intel wanted to go full 32-bit with capability-like segments right after 8080 with i432. It took way too much time to design, so they released 8086 as a stair-step to 432. It still took too much time, so they released 286. And when i432 was ready it turned out painfully slow anyway and x86 was completely entrenched because of PC platform so they bite the bullet.

by senfiaj 4mo ago

flohofwoe 4mo 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 4mo 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 4mo 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 4mo 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
    - mschaef 4mo ago
      I should preface this by saying I'm taking about x86 segmentation in general. On the 8086 you're right, but the 8086 can't address 2MB of memory to begin with. On the 80286 in protected mode, the situation is different in the way I'm about to describe. The memory itself doesn't have to be contiguous. 2MB of 64K segments maps to 32 segments. So you need 32 locations in physical memory capable of storing 64K. The programming model for addressing that block of memory necessarily includes both segment selectors and offsets. The segment selectors are indices into a segment table that contains the base address of each of the 32 segments. As long as the segment selectors themselves can be allocated contiguously in the segment table, you have enough to be able to compute which segment you need for which address in the 2MB range. It's the indirection through the segments table that maps it to physical addresses that do not need to be contiguous. Raymond Chen talks a bit about how it worked in Windows 3.x here: https://devblogs.microsoft.com/oldnewthing/20171113-00/?p=97386 https://devblogs.microsoft.com/oldnewthing/20171113-00/?p=97...
      - senfiaj 4mo ago
        >> 8086 can't address 2MB of memory This was just for illustration, not claiming that actual 8086 does this. >> Raymond Chen talks a bit about how it worked in Windows 3.x here: https://devblogs.microsoft.com/oldnewthing/20171113-00/?p=97 https://devblogs.microsoft.com/oldnewthing/20171113-00/?p=97... 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. Paging later made this kind of thing look like one flat array, a thing segmentation could not: making non-contiguous physical RAM appear contiguous to the program.
        mschaef 4mo ago
        > 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 bypassed if you need to for whatever reason. I'd argue that these are useful engineering abstractions that made the best of a less than ideal situation. (The reality of the world being that there are no "ideal" situations... you have to work with what you have at the moment to solve the problem you have. These days, I'd argue that a pointer into a 'flat' memory space is counter productive to the extent it hides issues around cache hierarchy, NUMA, etc. In 1986, we had to worry that a flat memory space looked discontiguous. In 2026, we have to worry the a discontiguous memory space looks flat.
pjc50 4mo ago
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.
- peterfirefly 4mo ago
  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.
  - senfiaj 4mo ago
    If I'm not mistaken 286's protected mode wasn't really that popular because it breaks real mode DOS programs. Meanwhile, 386's 32-bit protected mode with paging and virtual 8086 mode was a big success.
tliltocatl 4mo ago
Intel wanted to go full 32-bit with capability-like segments right after 8080 with i432. It took way too much time to design, so they released 8086 as a stair-step to 432. It still took too much time, so they released 286. And when i432 was ready it turned out painfully slow anyway and x86 was completely entrenched because of PC platform so they bite the bullet.