OSDev.org

i have read that most nowadays os use the flat memory model, which looks at memory as one big chunk of memory...how do these os handle relocation..for me, the most natural thing to do would be to assign every program its own segment so it can always be sure that a reference to say memory location 3 is always interpreted as a reference to location 3 of the same program...but if you use the flat memory model, i imagine that "burning" the memory references into the executable code is not possible as you never know where in memory your code will be located and every reference you make is to the lower end of memory...whats the trick here??

Hi,

Basically, the x86 has 2 methods you can use to separate program spaces: segmentation and paging.

It looks like segmentation support will soon become 'legacy', as long mode cannot use a segmented memory model. I have never written a segmented OS, but all the reading I have done indicates that it is a pain in the proverbial. This may be because if you are using task-descriptors (which can only appear in the GDT, not LDT's), you are limited as to how many tasks you can run at the same time (you can only have 8192 GDT entries). If you think that you have to have LDT entries, with the LDT containing different CS and DS descriptors, you can see that the whole thing could quickly become muddled.

So, if you assume that segmentation is more hassle than it is worth, that leaves us with paging.

In this system, virtual memory is mapped to physical memory using a page directory and page tables. If memory does not appear in the current page directory, it does not exist (as far as the current application is concerned). This means, you can link all your user-mode programs to 0x100000 (say).

For each program, you load a different page directory. As far as your program is concerned, it is running at 0x100000. In reality, the actual binary could be anywhere in physical RAM (often, the physical pages are not even contiguous). This allows you to have, for example, 100 different processes running at 0x100000. As long as the correct page directoy is loaded at the correct time for the appropriate process, your user programs will all be happy.

Another advantage of paging, is that you can have your kernel mapped to 0xC0000000, for example, in each process space. When your user program calls a kernel function, you do not then have to switch memory spaces to run that kernel code. Paging also allows you to easily share memory between processes (just map a physical page in to 2 process spaces).

I hope this clarifies things a little - sorry to ramble

Cheers,
Adam

Basically, the x86 has 3 methods you can use to separate program spaces: segmentation and paging.

Hehehe, you need more coffee Adam...

JamesM

D'oh!

Corrected in original post.

Adam

AJ wrote:Hi,

Basically, the x86 has 2 methods you can use to separate program spaces: segmentation and paging.

It looks like segmentation support will soon become 'legacy', as long mode cannot use a segmented memory model. I have never written a segmented OS, but all the reading I have done indicates that it is a pain in the proverbial. This may be because if you are using task-descriptors (which can only appear in the GDT, not LDT's), you are limited as to how many tasks you can run at the same time (you can only have 8192 GDT entries).

1) Who on earth is going to have 8191 processes running at a time?
2) You don't *have* to use the tss, do you?
3) Minix 3 has only one tss; the trick being that every time a process is started, the tss is loaded with the right values for that process!

Absolutely, that's the normal way to do things.

I guess I was just mentally drawing multi-TSS based switching and segmentation together - I consider both of them to be obsolete (or they will be in the near future). I do my multitasking using the software method (one TSS) and using different page directories.

To answer question 2, yes, you do need a TSS if you plan to do multitasking. The Intel manuals (I forget which section off the top of my head!) seem to recommend loading a TSS regardless of whether you plan to multitask or not - almost as a routine part of being in protected mode.

You are very welcome to use segmentation if you like - just be prepared that most source you will read does not use segmentation and I would expect that Intel won't be working much on improving segmentation mechanisms in the future (whereas they almost certainly will be adding to paging features).

You may not want 8191 processes running, but why impose an artificial limit to your OS if you do not need to?

Cheers,
Adam

1) Who on earth is going to have 8191 processes running at a time?

you might be surprised how quickly those processes add up -- esp in a micro-kernel

2) You don't *have* to use the tss, do you?

To answer question 2, yes, you do need a TSS if you plan to do multitasking. The Intel manuals (I forget which section off the top of my head!) seem to recommend loading a TSS regardless of whether you plan to multitask or not - almost as a routine part of being in protected mode.

thats because the TSS has nothing to do with multi-tasking -- it has to do with managing permissions -- you dont need one if you run everything in ring0 (even when multi-tasking), but you always need one if anything runs in any ring other than ring0 (and, iirc, in LMode you need one even in ring0)




basically, most people ignore segmentation because it is a lot more complicated (and not supported on other hardware platforms -- including x86-64)

paging works very well for this job, and provides a simple, and large, address space for application usage -- segmentation can get very complicated when you must expand segments (that or give a low memcap -- anything else is just a more complicated form of flat mode), as the application must use a single area (meaning dealing with fragmentation), either contiguous physical memory, or using both paging and segmentation, which makes things even more complicated

of course an application could use multiple segments instead of expanding a single segment, but most compilers dont handle that very well