Shulou(Shulou.com)11/24 Report--

This article comes from the official account of Wechat: low concurrency programming (ID:dibingfa). Author: flash.

Original title: "the sixth time | solve the historical burden of segment registers first"

With a novel-reading mentality, this series will read and appreciate all the core code of Linux 0.11 from the order of code execution after boot, and understand the technical details and design ideas of the operating system.

You will follow me, watching an operating system start from nothing, step by step to achieve its complex and exquisite design, after reading this series, I hope you can sigh that the original operating system source code is this stupid thing.

The following is a list of published articles. For more information about this series, you can start with the opening words.

Opening words

First time | the first two lines of code

The second time | make room for yourself.

The third time | make the most basic preparations.

The fourth time | put the other parts of your hard disk into memory as well.

Fifth time | the last time to toss the memory before entering the protected mode

The GitHub address of this series is as follows

Https://github.com/sunym1993/flash-linux0.11-talk

-the text begins-

The book follows the last time, last time we talked about, the operating system tossed about the memory, and then the memory layout will not change for a long time, and finally stabilized, now it looks like this.

0 address at the beginning of the storage of all the code of the operating system, that is, the system module, the 0x90000 location of dozens of bytes after the storage of some device information, convenient for future use.

Memory address length (bytes) name 0x900002 cursor location 0x900022

Extended memory 0x900042 display page 0x900061

Display mode 0x900071 character columns 0x900082 unknown 0x9000A1

Show memory 0x9000B1

Display status 0x9000C2 graphics card property parameter 0x9000E1

Number of rows on screen 0x9000F1 number of screen columns 0x9008016

Hard disk 1 parameter table 0x9009016 hard disk 2 parameter table 0x901FC2

Is the root device number very clear? But don't be happy too early, the refreshing memory layout is a great way to facilitate the follow-up operating system!

The real first big project is going to be carried out, and that is the mode transformation, which needs to be changed from the current 16-bit real mode to the later 32-bit protection mode.

Of course, although it is a very difficult project, but in terms of the amount of code, it is pitifully small, so there is no need to worry too much.

It is very troublesome to talk about here every time, because this is the historical burden of x86. Today's CPU almost always supports 32-bit mode or even 64-bit mode, and there are few CPU that only stay in 16-bit real mode. So we have to write a piece of code for schema conversion for this historical burden, and if Intel CPU were redesigned without considering compatibility, then today's code would be much less or no longer exist.

So don't worry, if you understand, you will understand, if you don't understand, forget it, and relax.

I'm not going to directly tell the difference between protected mode and protected mode, let's just follow the code and savor it.

This is still the code in the setup.s file.

Idt_48; load idt with 0 gdt_48; load gdt with whatever ropriateidt_48: .word 0; idt limit=0. Word 0; idt base=0L are two lines of instructions that you can't understand. Don't worry.

To understand these two instructions, it involves the first difference between real mode and protected mode. We are still in real mode, remember how CPU calculates physical addresses in this mode? If you don't remember, look at the first two lines of code in the first time.

That is, the segment base address is moved four bits to the left, plus the offset address. For example:

Don't you think it's awkward? something even more awkward is coming. When CPU switches to protected mode, the same code and memory address are calculated differently. Is it exasperating?

What has it become? The value stored in the ds register is called the segment base address in real mode and the segment selector in protected mode. The segment selector stores the index of the segment descriptor.

Through the segment descriptor index, you can find a segment descriptor from the global descriptor table gdt, in which the segment base address is stored.

The segment base address is taken out and added to the offset address to get the physical address. The whole process is as follows.

Why don't you just say if it's annoying? The same piece of code, the results in real mode and protected mode are different, but there is no way, we have to consider the historical burden of x86, who makes us have no other CPU to choose from.

To sum up, segment registers (such as ds, ss, cs) store segment selectors, which look for segment descriptors in the global descriptor table and extract the segment base address.

Well, the question naturally arises, what does the global descriptor table (gdt) look like? Where is it? How do you let CPU know where it is?

Never mind what it looks like, it must be another troublesome data structure, let's start with where it is. It's in memory, so how do you tell CPU where the global descriptor table (gdt) is in memory? The answer is that the operating system stores this location information in a register called gdtr.

How do I deposit it? That's the instruction.

Gdt_48 where lgdt means to put the following value (gdt_48) in the gdtr register, the gdt_48 tag, and let's see what it looks like.

Gdt_48: .word 0x800; gdt limit=2048, 256 GDT entries. Word 512 0x9; gdt base = 0X9xxxx you can see that the tag position represents a 48-bit data, of which the high 32 bits store the memory address of the global descriptor table gdt

0x90200 + gdt

Gdt is a tag that indicates the offset in this file, while this file is setup.s and is compiled in the memory address of 0x90200, remember? So add the value of 0x90200.

Then the gdt tag is the real data of the global descriptor table in memory.

Gdt: .word 0x07FF; 8Mb-limit=2047 (2048*4096=8Mb) .word 0x0000; base address=0 .word 0x9A00; code read/exec .word 0x00C0; granularity=4096, 386.word 0x07FF; 8Mb-limit=2047 (2048*4096=8Mb) .word 0x0000; base address=0 .word 0x9200; data read/write .word 0x00C0 Granularity=4096, no need to worry about the details, follow me to see the main points.

According to the previous segment descriptor format.

It can be seen that there are three segment descriptors in the current global descriptor table, the first is empty, the second is the code segment descriptor (type=code), the third is the data segment descriptor (type=data), and the second and third segment descriptors have a segment base address of 0, that is, when the logical address translates the physical address, the segment base address is found through the segment selector, whether it is the code segment or the data segment. Then the physical address will be directly equal to the logical address given by the programmer (the offset address in the logical address, to be exact). Just remember that.

There are a lot of details about the specific segment descriptor, so we won't expand it. For example, the high 22 bits here indicate whether it is a code segment or a data segment.

Next, let's take a look at the current memory layout, regardless of the proportion.

Here I also draw the idtr register, this is the interrupt descriptor table, and its principle is the same as the global descriptor table. The global descriptor table is used to let the segment selector look for the segment descriptor, while the interrupt descriptor table is used to find the address of the interrupt handler in the interrupt descriptor table when an interrupt occurs, and then jump to the corresponding interrupt program to execute it.

Okay, today we will talk about, the operating system set a global descriptor table gdt, so that after switching to protected mode, you can go there to find segment descriptors, and then piece together the final physical address, this is the purpose. Of course, there are a lot of paragraph descriptors that don't just translate to the final physical address, but that's later.

This is just one of the preparations for entering protected mode, and there is still a long way to go. If you want to know what happens in the future, listen to the next decomposition.

-extended data in this report-

For the conversion from logical address to linear address in protected mode (physical address when paging is not enabled), see Intel manual:

Volume 3 Chapter 3.4 Logical And Linear Addresses

For the structure and detailed description of the segment descriptor, see the Intel manual:

Volume 3 Chapter 3.4.5 Segment Descriptors

For example, the division of data segments and code segments mentioned in this article, in fact, there is a more subdivided access control.

-about this series-

The opening words of this series look at this.

Flash new series! You call this stupid thing the operating system source code.

The extended materials of this series can be seen here (you can also click to read the original text). There are a lot of interesting materials, questions and interactive participation projects. I hope you will participate in the continuous update.

Https://github.com/sunym1993/flash-linux0.11-talk

The global perspective of this series

Finally, I wish everyone can catch up to the end of the series, as long as you dare to continue to catch up, and understand the content of each time, I dare let you say at the end of the series, I am very familiar with Linux 0.11.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.