OSDev.org

First of all, I'm aware that paging is a more suitable way of implementing memory protection between processes and processes/os and that long mode expects a flat memory model, so segmentation is kind of deprecated.

Anyway, going back to the 286, where paging was not avaiable, how the OS is supposed to implement memory protection. I see we can define up to > 8000 segment entries on GDT. So I guess it should be possible to give a segment (or some separated segments for code,data,stack) for each process.

But what if, in the middle of execution, a process asks the kernel for more memory. It might be the case that the process's segment can't be extended, and so I suppose the kernel would have to create another segment and return the descriptor to the process (Let's forget for a moment the fact that the process should have been compiled with a compiler that supports a non-flat memory model). Giving one segment per memory allocation seems cool, since buffer overflows would cause a GPF. On the other hand, I guess 8000 segments is not enough to hold every allocation of every process. And worse, the process would have to constantly load different segments on DS to manipulate its data, and I guess it wouldn't be viable, would it?

So, what did Intel(?) had in mind when giving segmentation as the only memory protection feature on the 286?

You have just enumerated most of pitfalls of x86 protected mode segmentation and why 286 was broken; congrats.

OK, but anyway, they had a model in mind on how operating systems would implement memory protection. The question is, what they were probably thinking:

1) That process would have to request all of its memory on creation - ie that they wouldn't be able to ask for more memory on execution?

2) That 8000 segments were enough at that time to hold every process's chunks of allocated memory?

Bear in mind that when the 80286 was designed 1MB was a lot of memory.

And note that you can swap descriptors in and out (ignoring performance factor), so that the actual limit is having 8192 descriptors simultaneously.

Furthermore, you can't really adopt the memory accessing model for paging to segment and expect it work best. It's probably better to use the lock/unlock buffer mechanism for segment model instead of allowing most freedom access.

iansjack wrote:Bear in mind that when the 80286 was designed 1MB was a lot of memory.

...and, more importantly, that if you're running on a 286, your upper limit is 16MB of memory. 8192 selectors is more than enough to map the entire 16MB space several times over. (Assuming you do one selector at each privilege level for code and data on every 64k boundary, you'd end up using a total of 2048 selectors.)

ar5007eg wrote:OK, but anyway, they had a model in mind on how operating systems would implement memory protection. The question is, what they were probably thinking:

They probably wanted to give programmers both options you mention.

1) That process would have to request all of its memory on creation - ie that they wouldn't be able to ask for more memory on execution?

Even with one (data) segment per process, this isn't necessarily the case. If a program is using less than 64kb, the segment limit can always be extended after the program is started. Even if there isn't room to extend the segment limit at location of the current segment base, the segment can always be copied to a location with more room with a new limit, and the descriptor rewritten to reflect the new location.

2) That 8000 segments were enough at that time to hold every process's chunks of allocated memory?

Given the expense of RAM at the time, it was enough. The 286 wasn't really that bad a processor for its era. Its problem was back-compatibility (it couldn't run most programs designed for the 8086 in protected mode) and forward-compatibility (keeping the 386 back-compatible with it put constraints on the 386, including the limited number of segments and the fact that 286 segmentation couldn't be integrated well with paging, that made segmentation useless on the 386 except for back compatibility).

Hi,

MDenham wrote:

iansjack wrote:Bear in mind that when the 80286 was designed 1MB was a lot of memory.

...and, more importantly, that if you're running on a 286, your upper limit is 16MB of memory. 8192 selectors is more than enough to map the entire 16MB space several times over. (Assuming you do one selector at each privilege level for code and data on every 64k boundary, you'd end up using a total of 2048 selectors.)

Yes.

The other thing to remember is that back then the "PC" was a Personal Computer. It wasn't intended to be used as a server or mainframe (IBM had other products for that, like System/360) and didn't need features intended for multi-tasking and multi-user systems.

Basically, "80286 protected mode" was just an extension to the real mode segmentation that "PC" software was using at the time; and it wasn't something designed to compete with the virtual memory management features found in servers and mainframes.

Of course as technology progressed a lot of the features from "big iron" found their way into smaller (personal/desktop) systems; including multi-tasking, virtual memory management, virtualisation, etc; and now it's hard to imagine a CPU without paging being used for anything other than small embedded systems.


Cheers,

Brendan

ar5007eg wrote: Anyway, going back to the 286, where paging was not avaiable, how the OS is supposed to implement memory protection. I see we can define up to > 8000 segment entries on GDT. So I guess it should be possible to give a segment (or some separated segments for code,data,stack) for each process.

Not so. The GDT in a segmented design is used primarily for the OS/device-drivers, that needs to access global data. Each user process will be given a LDT, and all its memory allocations would be mapped to the LDT, given 8192 selectors per process. The OS could also allocate kernel-data in the LDT if they are on behalf of the process and doesn't need to be global.

ar5007eg wrote: But what if, in the middle of execution, a process asks the kernel for more memory. It might be the case that the process's segment can't be extended, and so I suppose the kernel would have to create another segment and return the descriptor to the process (Let's forget for a moment the fact that the process should have been compiled with a compiler that supports a non-flat memory model).

The best option is to return the same descriptor, but with a different base & limit. That way, the grown segment becomes identical for the users of the data.

ar5007eg wrote: Giving one segment per memory allocation seems cool, since buffer overflows would cause a GPF. On the other hand, I guess 8000 segments is not enough to hold every allocation of every process. And worse, the process would have to constantly load different segments on DS to manipulate its data, and I guess it wouldn't be viable, would it?

At the time of the 286, it was not a problem. On today's machines it is a problem, but can be solved by combining segmented allocations with flat, so that small allocations in huge numbers use flat memory while larger use segments with exact limit checking. The application / OS then uses 48-bit pointers for everything.

Brendan wrote: The other thing to remember is that back then the "PC" was a Personal Computer. It wasn't intended to be used as a server or mainframe (IBM had other products for that, like System/360) and didn't need features intended for multi-tasking and multi-user systems.

Basically, "80286 protected mode" was just an extension to the real mode segmentation that "PC" software was using at the time; and it wasn't something designed to compete with the virtual memory management features found in servers and mainframes.

Of course as technology progressed a lot of the features from "big iron" found their way into smaller (personal/desktop) systems; including multi-tasking, virtual memory management, virtualisation, etc; and now it's hard to imagine a CPU without paging being used for anything other than small embedded systems.

Not so. The 286 does have a TSS, and it even supports hardware task-switching. The TSS contains per-process kernel stacks and per-process LDT, so I hardly think Intel didn't think about multitasking. OTOH, they certainly didn't have SMP in mind (as the hardware task-switching mechanism is unsuitable for SMP implementations), but why would they?

Hi,

rdos wrote:

Brendan wrote:The other thing to remember is that back then the "PC" was a Personal Computer. It wasn't intended to be used as a server or mainframe (IBM had other products for that, like System/360) and didn't need features intended for multi-tasking and multi-user systems.

Basically, "80286 protected mode" was just an extension to the real mode segmentation that "PC" software was using at the time; and it wasn't something designed to compete with the virtual memory management features found in servers and mainframes.

Of course as technology progressed a lot of the features from "big iron" found their way into smaller (personal/desktop) systems; including multi-tasking, virtual memory management, virtualisation, etc; and now it's hard to imagine a CPU without paging being used for anything other than small embedded systems.

Not so. The 286 does have a TSS, and it even supports hardware task-switching. The TSS contains per-process kernel stacks and per-process LDT, so I hardly think Intel didn't think about multitasking. OTOH, they certainly didn't have SMP in mind (as the hardware task-switching mechanism is unsuitable for SMP implementations), but why would they?

A "multi-tasking and multi-user system" is a combination of hardware and software. It's different to something that is only hardware (e.g. a CPU), and different to something that only supports multi-tasking. A "multi-tasking and multi-user system" doesn't need CPU support for anything (as software can make up for whatever hardware lacks, even if it is via. emulation).

CPU features intended for "multi-tasking and multi-user systems" are features intended to improve the CPU's ability to compete against large servers/mainframes that "multi-tasking and multi-user systems" previously used. These features include things like decent virtual memory management (paging), fast virtualisation (virtual8086 mode), support for enough physical RAM (20-bit physical addresses vs 32-bit physical addresses), etc. 80286 had none of these things. 80386 had all of these things.


Cheers,

Brendan

Brendan wrote:
The other thing to remember is that back then the "PC" was a Personal Computer. It wasn't intended to be used as a server or mainframe (IBM had other products for that, like System/360) and didn't need features intended for multi-tasking and multi-user systems.

Basically, "80286 protected mode" was just an extension to the real mode segmentation that "PC" software was using at the time; and it wasn't something designed to compete with the virtual memory management features found in servers and mainframes.

Keep in mind that the 286 was released less than 6 months after the PC and was almost certainly in development before the PC was released. Intel didn't have the IBM PC specifically in mind when they designed the 286, and it's certainly obvious from the design of the 8086 compatibility features on the 286 (real-mode with no v86-equivalent mode and no means of getting back to real mode from protected mode) that Intel didn't have much of an idea of what sort of software would be written for 8086 PC's.

Hi,

linguofreak wrote:

Brendan wrote:Basically, "80286 protected mode" was just an extension to the real mode segmentation that "PC" software was using at the time; and it wasn't something designed to compete with the virtual memory management features found in servers and mainframes.

Keep in mind that the 286 was released less than 6 months after the PC and was almost certainly in development before the PC was released. Intel didn't have the IBM PC specifically in mind when they designed the 286, and it's certainly obvious from the design of the 8086 compatibility features on the 286 (real-mode with no v86-equivalent mode and no means of getting back to real mode from protected mode) that Intel didn't have much of an idea of what sort of software would be written for 8086 PC's.

In 1972, IBM added virtual memory to their System/370 mainframe, which were 32-bit machines with 24-bit addressing.

In 1981, IBM PC was released, and IBM would've needed to design the hardware and write software/firmware for it, so they would've started designing it 1980.

In 1982, Intel released both the 80186 and the 80286 (2 years after Intel would've found out about IBM's "PC" plans, and 10 years after IBM mainframes started using virtual memory).

In 1983, IBM extended System/370 to 31-bit addressing.

In 1985, Intel released the 80386, with virtual memory (13 years after mainframes had it) and 32-bit addressing


Cheers,

Brendan

Brendan wrote:In 1982, Intel released both the 80186 and the 80286 (2 years after Intel would've found out about IBM's "PC" plans, and 10 years after IBM mainframes started using virtual memory).

This is when the 286 was released. Development would have started much earlier (probably around 1980 if the development time for the 8086 is any indication).

And I fail to see how mainframes are relevant here.

Mainframes are relevant because the technology migrated from them down to PCs. Not just memory management features, but also peripherals like floppy disks and Winchester disks and concepts such as RAID and SMP - not to mention networking.

You can't consider the development of PCs without also looking at that of mainframes and minis.