Try to get a hold on "operating systems" by Lister. The book is easy reading and explains about every aspect of a modern operating system of terms of task switching, virtual memory, paging etc. http://www.google.com/url?sa=t&sourc...Va2KUOGx66gljQ

It doesn't feel good to see someone asking for help (you!), asking very detailed questions, very fundamental and then start whining over the number of pages a manual consists of. Had you even opened those manuals, then you should have noticed that you can skip entire parts of explanations which are already obvious to you. If that isn't the case: do you expect us to write it all down here for you in nice digestive parts so you can lean back and have the knowledge shoved into your mouth? You do you think we gained that knowledge? Handing out questions on the university campus and asking for answers the next day?

Again, there is a wealth of knowledge out on the internet, the Wikipedia to start with, which gives a thorough and correct explanation of most if not all of the terms you are looking for.

jlinkels

1 members found this post helpful.

No, you didn't. Because I know for sure (rechecked myself before asking you) that in that whole output there are switches controlling where 'ld' looks for libraries and output format.

Vanishingly rare? No.

Here are the numbers I have by summing the entries in an industry standard directory:

So, by part number at least, unless you think that 63.5% is vanishingly small, and 35.5 (or 36.5) percent is a lot bigger, it is a difficult case to make.

(There are some peculiar corner cases, including one dual core device for which one core has an MMU and the other doesn't, but I've included that in the full implementation because it really doesn't affect the overall conclusion, although you could argue for another approach. And there are some part numbers, primarily for soft core devices, which are available either with or without, depending on which license you buy, but again it doesn't affect the overall outcome to any real extent.)

But I don't understand those kinds of things. It seems like you always expect me to magically know everything in advance, and that everyone you're helping already knows what you do. But I don't, I mean why would I be asking you a question if I already knew I was smarter than you at the subject?

But I did look at the whole thing ( at developers for putting --architecture flag in the first page).

I got the Intel manual and it isn't as bad as I thought. I see it also says it will contain some other things I couldn't find the answer to, like floating-point calculations.

Lame excuses. As I wrote you before, it is your duty to read, comprehend and analyze the text. The text is structured, i.e. as much as possible the items are described independently. The items you were supposed to pick do not depend (WRT understanding) on other items.

As I wrote you before, the items you had to pick up are described in plain English, without anything related to computer science or math.

I found this nice book online — http://en.wikibooks.org/wiki/X86_Assembly/

Anyway, tell me if this is correct:

The segment registers contain the addresses of separate blocks to be used for the stack, code, and data, and this is so you can access the whole memory even though it cannot all be addressed by the CPU's word size.

Can segmentation be used in a program running under an OS or not, and why?

Is segmentation used by the OS to manage memory?

That is vague enough it could be considered correct or incorrect depending on your point of view.

Under some OS, yes. Under Linux, I'm pretty sure the answer is almost entirely "no". X86 architecture and even X86_64 architecture require the OS to deal with some odd remnants of the segmented design even if the OS is based on "flat" addressing. But in practical terms, segmentation is not used in Linux.

What OS?

If you mean Linux or a recent version of Windows, then no.

Overall, I don't think you're going to learn anything from posted answers to such vague questions about complicated and largely obsolete topics.

There are some good web pages you could read about Linux memory management and how it uses the page table system of X86 and X86_64 architecture (try google, I don't have URLs handy). If you really want to understand more obscure topics such as segmentation, first learn enough asm that you can even grasp the concepts, then read it in the Intel processor documents. Generalized answers in a forum to bad questions aren't really going to teach you anything.

Well, I don't know.

So modern OSes do not use segmentation whatsoever, right?

And is it right that other CPUs like ARM and PowerPC don't have segmentation?

And does this mean that segmentation can be completely ignored for all practical purposes?

I guess I will do a few searches later, not quite sure what to look for, though.

Yes and no :-) For reasons of backward compatibility for example, each x86(_64) CPU starts in real mode using the segmented memeory address (segment addressffset in segment). Though, when Linux is "called" by the boot loader, it also starts in real mode up to the point where it switches to protected mode. I once read about Linux that it only uses segmentation where really imposed by the architecture, so just as minimal as possible.

I don't know :-) I would have to search for this ...

Just like above, some parts must be done in segmentation mode. E.g. switching to protected mode ;-)

Just tried from a different point-of-view ... Why do you want to know so many details about the protected mode? Just for interest or do you plan to write some OS/boot code in protected/real mode?

- Andi -

Hi, again MTK358.

Let's go back to a previous post:
And let's also introduce two new terms:DOS used to run in "real mode" and used "segmented addressing".

Linux runs in "protected mode" and uses "linear addressing".

There's no "magic" or "mystery" with segment registers: it's just a base address (the address in the segment register) plus an offset. Segment registers were there on 8088 CPUs in DOS; they're still there on Pentium CPUs in Windows or Linux.

But you're correct: with linear addresses, you don't need to worry about them. The 32-bit "offset" *is* the whole address.

This link might help clarify:
'Hope that helps .. PSM

OK.

I don't know either, I guess I will Google it.

But once your boot code switches to protected mode, you can forget about segmentation, right?

Maybe.

Once I fully understand it

And?

So linear addressing is when the program accesses memory by it's address, and segmented addressing is when a program accesses stack memory relative to the stack segment, code relative to the code segment, etc., right?

First, I would have selected the term "flat addressing" rather than "linear addressing" for the contrast to "segmented", that paulsm4 made.

Second, you're still giving simplistic enough descriptions that they are too ambiguous to be right or wrong:

When talking about the inner details of addressing systems, to act like there is a fundamental meaning of the word address as you did above interferes with understanding.

Quick (I hope) detour in the basics of 386 32 bit protected mode addressing addressing:

You have a segmented address consisting of a 16 bit segment selector and a 32 bit offset.

The CPU uses the 16 bit segment selector for a table lookup to get various info to combine with the 32 bit offset to compute a 32 bit linear address.

The CPU uses page tables (same as non PAE 32 bit X86 Linux now uses) to translate the 32 bit linear address to a 32 bit physical address.

The memory controller translates the 32 bit physical address into a set of select and strobe and internal address signals to get to an actual chunk of ram.

Now contrast that with "flat addressing". The program uses a 32 bit (for X86) or 64 bit (for X86_64) address, which acts like the linear address described above and gets translated as above to a physical address and then translated again by the memory controller.

In 32 bit X86 flat addressing designs, the CPU design won't let you turn off the translation from segmented address to linear address (without losing the rest of 32 bit protected mode and just having "real" mode). So instead the OS programs the tables used by segmented addressing so that the linear address after that first translation will equal the offset part of the address before the translation.

In X86_64, almost all of the X86 segmented design is disabled by the CPU, so the 64 bit offset is unavoidably the same as the 64 bit linear address, and the bottom 48 bits of that linear address are translated by the CPU using the page tables into a physical address.

<never mind >

WTF?