OSDev.org

Hi OSDevers,

Have you ever tried to implement Segmentation first, but for any reason you realised that's better to switch off to Paging? If yes, what was the problem?

If you still using Segmentation, how do you feel about that? Is that your final choice? Did you ever face any issue which makes you worrying about Segmentation?

Thanks in advance.

P.S. General ideas are welcome, however I look more for the people who has already implemented Segmentation in their [working] OS projects.

P.P.S. My first post!

Not really an answer to your question, but I would have thought that most people starting on a new OS would want to take advantage of the extended register set and other features of 64-bit processors (talking x86). That being the case, the question ceases to have relevence.

Thanks iansjack for the reply. Well, honestly I guess I can't understand what you meant there clearly, so if you could add more description that would be great. By the way, are you trying to say Segmentation is somehow legacy by now? I can't understand why you mention 64-bit features. As far as I know, there are clear pros and cons when you choose Segmentation over Paging, so you may decide to implement your Segmentation on your 64-bit machine as well.

P.S. I'll look to see what are the other options available on 64-bit platforms, maybe there are totally new approaches with the same or probably more advantages as Segmentation out there which I'm not concern about them yet.

Well, there's a limit on how many segments you can have defined in GDT and addressable by the segment registers. Secondly I don't have to allocate all of the memory for the process, which is only available with paging. Swapping is only available with paging. Memory sharing is easier with paging.

Thanks Nessphoro for the explanation. I never thought about the GDT limitations.

One more question, are you guys aware of any real-world general-purpose OS, which relies on Segmentation instead of Paging?

Guys, when I look at tutorials and some other resources on the 'net, I got the feeling that hey, Segmentation is still alive! you can include it in your memory management options when you designing your OS, but it seems that it is dead in practice. Maybe I'm missing some points, but, is there ANY advantages for choosing Segmentation over Paging for a modern OS?

I guess I'm a little bit confused because of a few updated tutorials and lot's of old tutorials.

P.S. sorry for (smoothly) moving to another topic ... If I need to change the topic title or start a new one, please let me know. :)

Segmentation doesn't really exist in long mode - at least not the segmentation that you will be familiar with in Protected Mode. And it is a prerequisite of long mode that you use Paging. So if you want to use 64-bit features then you really need to implement Paging, and I would say there is little point is using Segmentation. Long mode is designed with a flat address space in mind. You really need to read the manuals to understand this.

Yes, I would say that Segmentation is pretty much a legacy technique now. Of course, many of the tutorials and examples that are to be found on the web are fairly old now and written for 32-bit processors. But we do have at least one champion of Segmentation here; perhaps he will come and put me right.

Segmentation exists in many guises on many platforms. i386 segmentation is a rather powerful implementation, but has been stripped in its successor because the majority didn't technically have any use for all it's features. Segmentation still provides elegant solutions to a few particular problems, but there's also a religious cult active that worships segmentation and preaches its use.

That said, segmentation is used in my OS a few steps beyond what's considered the minimum, but it isn't anything interesting currently.

386 segmentation is powerful compared to what exists on most other architectures, but I don't feel that *any* paged architecture really has a segmentation implementation that's powerful enough: Many of the benefits that segmentation gives on an unpaged architecture are also given by paging, and the 386 implementation of segmentation doesn't really lend itself to efficiently providing the benefits that paging alone doesn't provide.

Ideally, for instance, instead of specifying an offset, a segment descriptor would specify a page directory. That way, you don't have to wait for the result of an addition (offset + address) to figure out what page you're referencing before making a TLB lookup: you just concatenate the segment selector to your address and make the lookup.

Thank you guys for the answers, they were really helpful. :)

As the result, I guess I'd go for the Intel manual to see what features are still exists there, what are the pros and cons, etc. Still a little bit confused because for a long time I was thinking that Segmentation is something serious, now I feel a little bit guilty also to dump it for Paging! ... but anyways, let see what will happens after reading Intel manuals, I just hope they put enough effort to explain the truth about Segmentation there! :D

If you guys know any other helpful resources like a chapter of a book or an article which addressing the problem with a comparison to the recently available techniques, please let me know that, that would be really great and I would really appreciate that.

Hi,



Intel's manual will describe how segmentation works, what it's capable of and how to set it up; but it won't tell you what it could be used for, or the advantages/disadvantages of using it in various ways.

For a very rough guide, there are 4 possible combinations:

No segmentation, no paging: This means no protection, no way to isolate pieces of code from each other, no way to deal with fragmentation, no way to handle various virtual memory techniques (copy on write, swap space, memory mapped files, etc). Despite being "underpowered" it actually can make sense in very specific situations (e.g. an embedded thing that only runs one application and doesn't need any memory management).

With segmentation, no paging: There's 2 ways of doing this:

• small number of large segments. This solves the protection/isolation problem; but ends up being a huge disaster for everything else (memory fragmentation, copy on write, swap space, memory mapped files, etc).
• large number of small segments. This solves the protection/isolation problem and makes it more possible to do the other things (in an over-complicated and ugly way). The main disadvantage is that loading a segment register is slow, and when you're loading segment registers often it can be a serious performance problem.

Note that for both of these cases there's a "virtual address space size" shortage. For example, if you've got a 32-bit CPU with 12 GiB of RAM then you can't use most of the RAM. Don't forget that in long mode you have to use paging, so you can't use the "48-bit virtual addresses should be enough until next week" excuse in this case.

No segmentation, with paging: This is capable of doing almost everything, and (once you understand paging) it's relatively easy. The only thing it can't do is things like checking if array accesses are in range (but if you care about that then you should be using a managed language to begin with).

With segmentation and with paging: This is a pointlessly overcomplicated mess (use paging on its own, or using paging and a managed language).


Cheers,

Brendan

Thanks Brendan, that was nice!

Well, I was thinking of finding some key points on Intel manuals like "long-term deprecated" or i don't know, some new approaches maybe, but as I see it is not available in "long mode", I guess I seriously need to revise my design choices.

The thing that make it a little bit more complicated for me is that I'm making a new programming language for the operating system also, and I'm trying to combine couple of features to achieve more security and performance there. So, I really don't want to repeat whatever which has been made thousand of times earlier. I don't want to port C in my operating system and I don't want to use any popular (for example, in this case) memory management techniques for the sake of to-be-standard. I mean if I really find out that Paging is the best thing I can have, okay, I'd be happy to implement that, but before that I need to be sure that yeap, this is the best possible way to do that, otherwise I'd keep searching for the new approaches, even the craziest ones.

Anyways, I guess I need to split up my question into couple of more specific questions ... that would works better I guess.

But, guys, it was awesome for the very first topic! usually when I'm asking something in stackoverflow, I prepare myself for lot's of down votes! Here you understand me much better I guess! Thanks! :D

Most people do not port C (Compiler) to their OS, but they support some kind of compatible layer like POSIX, and the compiler comes as a by product.
Then porting POSIX itself is your own decision choice.


Perhaps those techniques are popular not because they are standard, but because are good technique itself (and therefore became standard).
For example the recursive paging technique.


Here people are happy to help if you show you've put your effort; on the other hand people don't like spoon-feeding.
So, welcome to the forum.

Thanks bluemoon! yes, you're are right! I will try to spend a reasonable time to understand the problem and trying to find out (at least) a solution for that before asking the question here, however it is really nice that you know there is a place where you can talk about your ideas to be sure that you're on the right track.

As I said, for example when I'm asking a question in stackoverflow most of the programmers trying to push you to go through a very well-known solutions. If your question sounds like reinventing the wheel, well you're pretty much close to lot's of down votes or even some comment which making fun of you. I'm happy that here you have some space for trial-n-error guys, for experimenting and learning things not by only reading books!

Anyways, cheers guys!

Using segmentation without paging is a bad design-choice. The only really useful approach for a segmented design is to use segmentation on top of paging.

Having gotten a long way with my 64-bit environment now (which uses only paging), and comparing it to my usual (segmented-paged) environment, I think I can conclude the pros and cons:

1. Syscalls in a segment-paged environment can be run without validation (the validation can be built-into the API by defining the appropriate selectors for user-mode). This is true even if applications are flat.

2. Syscalls in a paged-only environment needs extensive parameter evaluation in kernel before being passed to server.

3. Separation with segmentation in kernel is an adequate method of providing protection between modules in a kernel.

4. Separation with paging only in kernel is typically not an adequate method, instead many designs use a microkernel and let driver modules run in isolated user-address spaces. At least similar protection as with segmentation cannot be achieved without a microkernel design.

5. Long mode addresses can be used in a pseudo-segment related manner by treating the upper 32-bits as a segment, and keeping various pieces at "random" locations. However, typical uses of 64-bit mode use the 2G lower addresses or 2G higher addresses, which provide no protection at all in addition to a 32-bit flat memory model.

Since there are pros and cons of each of these designs, it is not possible to tell which is best and which is most effective. It also depends on the speed of segmentation and paging on the particular processor, and how syscalls are constructed by the OS.