Чё куда проецируется виртуальная память на физическую или наоборот?

Друзья!
То есть я не могу разобраться.
То есть я понимаю, что виртуальная память это типа память, а физическая это память по факту. На этом моё понимание заканчивается. И дошёл бы до ответа на этот вопос сам (может быть), занимаясь своим любимым делом (см. подпись), если бы сей автор ещё больше меня не запутал.

...Глава 13
http://wm-help.net/books-online/book/59464/59464-6.html#h13
Архитектура памяти в Windows.
Читаем:
" Другими словами, адресное пространство — всего лишь диапазон адресов памяти И, прежде чем Вы сможете обратиться к каким-либо данным, не вызвав нарушения доступа, придется спроецировать нужную часть адресного пространства на конкретный участок физической памяти."

Понятно. Чуть ниже читаем
"Чтобы зарезервированный регион адресного пространства можно было использовать, Вы должны выделить физическую память и спроецировать её на этот регион."

...Я и так врубиться не могу, а тут ещё путаница- чё куда мы проецируем- одно на другое или другое на одно?
Спасибо.

 

Друг на друга они спроецированы. Не пытайтесь найти здесь чёрную кошку.

 

Ну это ладно. А я хотел бы понять что на что необходимо проецировать, если нужно использовать некоторое адресно пространство?
Не может же быть, чтобы мы выделяли регион и проецировали его на физическую памятьи выделяли регион и проецировали физическую память на него?

Тут что-то одно должно быть.

 

amvoz
Почитай intel manuals, многое прояснится. Написано там на порядок лучше чем где-либо

 

Именно так. Если нужна куча, то она приращивается на этот участок проецируется произвольный участок физической памяти. Вот если нужен конкретный физический участок, то можно под него подобрать линейный.
А также еще есть расшаринные участки физической памяти одни библиотеки в разных процессах могут лежать по одним физическим адресам для экономии памяти.

 

На самом деле все просто. Эсть физическая память, т.е. грубо говоря планки с памятью. Например, 512 метровая. Есть виртаульная память, абстракция операционной системы. Для x86 в самом простом случае адресное пространство 32-х разрадное. 4 гигабайта виртуального адресного пространства это хорошо, но у нас то есть всего 512. Для этого ОС хранит для каждого процесса (и для себя в том числе) специальную табличку, которая говорит, гда искать виртуальные адреса в физической памяти. Соответственно, не все виртуальные адреса имеют связь с физическими, большинтсво просто никуда не указывает. При переключении процессов ядро должно загружать для нового процесса соответствующую табличку. Так, для 2 процессов одинаковые виртуальные адреса могут указывать на разные физические адреса. ( ну или на одни и те же, если данные адреса являются расшаренными).

 

Если нужно использовать физическое адресное пространство - никуда его проецировать не надо. По физадресу проц и обращается к RAM. Если нужно использовать виртуальное адресное пространство, проц спроецирует его на физическое и только после этого по найденному физадресу обратится к RAM. Как он это делает? Все просто. Если прграмма может обратиться по данному виртуальному адресу, значит ему в соответствие поставлен некоторый физический адрес. Соответствие задется таблицей. Отдельная запись в таблице говорит процу примерно о следующее: "виртуальные адреса с такого-то по такой-то (диапазон длиной 4096 штук адресов, то есть 1 страница) заменяй на физические адреса с такого-то по такой-то (тоже 4096 штук адресов)". Короче, "заменяй виртуальные на физические". Так виртуальное пространство отображается (проецируется) на физическое.

На самом деле нет никакой разници. Есть отображение - есть и обратное. (процу нужно именно отображение "виртуальный-->физический" ) При этом понятно, что некоторому физическому адресу (в контексте определенной таблицы) может не соответствовать ни одного виртуального, а некоторому виртуальному может не соответствовать ни одного физического. Так что kda дело говорит.

А вообще вопрос из разряда "что имел в виду автор?", а не "как это работает?". Надо знать ответ на вопрос, как по заданному виртуальному адресу найти физический, поставленный ему в соответствие. Или как построить таблицу страниц, чтобы конкретная страница отображалась в нужный участок физической памяти. Короче, читай "Intel architecture software developers manual. System programmers guide" Вроде, интеловские манописцы не грузят беллетристикой.

 

amvoz
лучше почитайте о страничной адрессаци или уже на крайняк
виндовс инсайд 5 часть

 

Ребята, мне непонятна вот такая маленькая деталь.

То есть, допустим, я загрузил какой-то исполняемый файл

LoadLibrary ("ima_faila.exe")

И стал работать с его заголовком. Так вот. Он занимает в виртуальном пространстве 4096 байт. Вопрос: сколько он занимает в физическом пространстве? Тоже 4096 байт. Так ведь? Это я сослался на _noobas_
(см. цитату).

А теперь. Данное утверждение можно распространить на всю виртуальную паять процесса. То есть есть виртуальные адреса под секцию кода (наример) занимают x байт- и физические адреса, которые им соответсвуют занимаю тоже x байт! Так тогда получается... Получается, что сумма всех адресов виртуальной памяти процесса равна сумме всех адресов физической памяти!
(тоже 4096 штук адресов)И меня тянет с этим согласиться. Ведь не может же такого быть, чтобы нескольким страницам виртуальноя памяти (двум, трём, десяти- щас неванжо) соответсовала одна физическая. Для каждой странице виртуальной памяти СВОЁ уникальное содержимое! (Даже учитывая, что каждай секция уменьшается на диске из-за выравнивания, но тем не менее!) Есть же ещё и ресурсы всякие и прочее.
...Но в физической памяти нет ведь 4-х гигов...

...Или так: НЕ ВО ВСЯКИЙ МОМЕНТ ВРЕМЕНИ оперативная память наполнена содержанием виртуальной. А когда я обращаюсь к адресу виртуальной памяти, ТОЛЬКО В ЭТОТ МОМЕНТ система соответствующую страницу предоставляет в оперативной памяти, наполнив её содержанием из диска!
Тогда вроде чё-то стыкуется.

Извините.

 

amvoz
Вообще говоря, именно виртуальная память отображается (проецируется) на физическую -- хотя бы потому, что страничный механизм процессора, использующийся для организации виртуальной памяти, преобразует виртуальные адреса в физические, а не наоборот. Когда цитируемый Вами автор проецирует физическую память на зарезервированный регион, он слишком вольно обращается с терминологией. Правильнее было бы сказать так: "Чтобы зарезервированный регион адресного пространства можно было использовать, Вы должны выделить физическую память нужного размера и отобразить (спроецировать) виртуальные адреса зарезервированного региона на эту физическую память".

Необязательно. ОС не обязана моментально загрузить запрошенный файл в физическую память, она лишь должна где-то там у себя пометить, что такой-то диапазон виртуальных адресов данного процесса занят образом такого-то файла (как именно это делается, в данном случае неважно). А вот когда произойдёт реальное обращение к какому-то виртуальному адресу из числа отведённых под файл, тогда ОС и обеспечит, чтобы нужный участок этого файла был реально загружен в физическую память. С точки зрения программы, работающей с таким файлом, можно считать, что файл находится в памяти -- на то виртуальная память и служит, чтобы "притворяться" реально существующей. Таким образом, получается, что заголовок, занимающий в виртуальной памяти 4096 байт, в физической может занимать 0 байт

Вот последнее утверждение и является, в общем-то, правильной. ОС держит в физической памяти лишь часть содержимого виртуальной памяти любого процесса. Если физической памяти не хватает, она начинает переписывать ненужные в данный момент страницы на диск (в файл или раздел подкачки) и загружать оттуда необходимые. Именно благодаря этому программы в сумме имеют намного больший объём виртуальной памяти, чем физически установлено на машине. Платить за это, естественно, приходится скоростью: подкачка страниц -- крайне медленная операция.

 

http://www.wasm.ru/publist.php?list=24
з.ы. тему не читал, но странно, что никто не дал ссылку.. Рихтер поверхностно пишет об этом.

 

а можно я еще добавлю
имеем таблицу по виртуальному адресу 0C0000000h

виртуальный адрес используется как индекс в этой таблице и по этому всегда постоянен

физический адрес это значение записанное в конкретном DWORD-QWORD по этому индексу, и может меняться

понятно что если 1 страница 4к то 11 бит виртуального и физического адреса одинаковые и по этому берутся из виртуального адреса и не хранятся в таблице

а вот примерно так выгледить код функции MmGetPhysicalAddress

Код (Text):

1. GetPhysicalAddress proc uses ebx dwAddress:DWORD
2.        mov eax, dwAddress ;загрузим в eax,ecx виртуальный адрес
3.        mov ecx, eax
4. ;вычислить индекс*8 %%%%%%%%%%%%%%%%%%%%%%%%%
5.        shr eax, 18 ;вычислить смещение в PDE это старшие 11 бит (PDE находится в том месте где таблица отображает сама себя)
6.        and al,11111000b ;обнулить последние 3 бита в PDE каждая ячейка по 8 байт
7. ;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
8.        add eax,0C0600000h
9.        MOV EDX,DWORD PTR DS:[EAX+4] ;EDX-EAX ячейка PDE 8 байт
10.        MOV EAX,DWORD PTR DS:[EAX]
11.        bt eax,0  ;Если флаг Valid (бит 0)установлен, то PDE действителен
12.        jc @F
13. errors:xor eax, eax ;идти в баню
14.        xor edx, edx ;идти в баню
15.        ret
16.     @@:bt eax,7  ;Если флаг Large Page (бит 7)установлен, то это страница 2м
17.        jnc str4k
18.        mov ebx,00000000000111111111111111111111b;обнулить
19.              ;старшие 11 бит,выделить смещение внутри станицы 2м младшие 21 бит
20.        jmp kones
21.  str4k:mov eax,ecx ;вычислим индекс во всем 8 метровом PTE
22.        SHR EAX,9 ;
23.        and al,11111000b ;обнулить последние 3 бита
24.        add eax,0C0000000h
25.        MOV EDX,DWORD PTR DS:[EAX+4] ;EDX-EAX ячейка PTE 8 байт
26.        MOV EAX,DWORD PTR DS:[EAX]
27.        bt eax,0  ;Если флаг Valid (бит 0)установлен, то PDE действителен
28.        jnc errors
29.        mov ebx, 00000000000000000000111111111111b ;обнулить
30.                  ;старшие 20 бит,выделить смещение внутри станицы 4к младшие 12 бит
31.  kones:and ecx,ebx ;старшие 11,20 бит
32.        not ebx
33.        and eax,ebx  ;обнулить флаги  
34.        and edx,111111b ;оставить последние 6 бит (используется только 38бит)
35.        add eax,ecx
36.        ret ;EDX-EAX физический адрес
37.  GetPhysicalAddress endp

 

IceT
ну так по делу я ему сказал путь почитает виндовс инсаид
там все подробно рассписано
а рихтера читать это для школьников
которые учаться создавать потоки и использовать мютексы - не более
ну и еще таймеры поюзать

 

Спасибо всем, SII, спасибо, чего-то проясняется.
Так я школьник и есть. Просто натыкаешься на такое вот "Когда цитируемый Вами автор проецирует физическую память на зарезервированный регион, он слишком вольно обращается с терминологией." (это про Рихтера) и встреваешь. Сами знаете, как важны правильные понятия, когда собственых знаний не хватает, чтобы мысленно подкорретировать автора.

 

А вот ещё вопрос, ребята. Я настаивать не буду, но всё же, чтобы тему отдельную не делать...
Вот здесь про защищённый режим.
http://www.wasm.ru/article.php?article=pipm02
Написано так:
"Процессор собирает в кучу три поля зеленого цвета и образует единый 32-х битный адрес. "

И красивая картинка.
...Я понять ничё не могу- как они собирает? Сплюсовывает, что ли? Вот эти значения?
[31:24] [23:16] [15:00]
Или что он с ними делает?

...И находятся ведь такие, кто с первого раза всё понимает...

 

amvoz
я вам уже сказал
найдите книгу по архитектуре i386 или i486
и прочтите с пониманием
сразу все вопросы отпадут
раз уж вам скачать виндовс инсаид так тяжело

а вы пытаетесь освоить полет на воздушных шариках не представляя сколько вам шариков нужно и как они вообще летают

не можно конечно вам все обьяснить
но зачем заниматься цитированием книг правда?

 

Да ничё не отпадёт.
100%.
И в своё время мне и Рихтера советовали и всех и на этот ресурс ссылку дали... Если авторы на самом деле так пишут (или переводчики переводят), то он так пишут ВСЕГДА, и в предлагаемых Вами ресурсами то же самое. Это проверено опытом.
Но я обещал не настаивать, за сим удаляюсь.

 

в мануалах все расписано для полных даунов кстати. все эти статьи и книжечки мусор по сравнению с ними. научись работать с тех документацией наконец.

не нужно тут только своим опытом махать. это ппц. редкий случай )

 

[П. И. Рудаков, К. Г. Финогенов]ЯЗЫК АССЕМБЛЕРА - УРОКИ ПРОГРАММИРОВАНИЯ

Неплохо описан защищенный режим процессора.
Еще можно Зубкова почитать.

P.S. могу кинуть на мыло если надо...

 

Тему к закрытию.

Естественно.
Рихтер мусор по сравнению с уроками Айзелиона уроки Айзелиона муср по сравнению с Крупником, а Крупник мусор по сравнению с Рихтером.
Так они по кругу все друг для друга мусор.

А я тебе говорю, что я по опыту знаю. А ты бесцеремонно подменяешь понятия. Я ничего не смыслю в системном программировании, но за свою жизнь много чему обучался, наверное, поболе твоего. И я тебе говорю, если ты сделал вид, что не понял, о чём речь: все мануалы, всю техническую документацию касаемо чего бы то ни было пишут люди о двух руках и одной голове и ты меня не переубедишь, что с процессорами дела обстоя не так. Кратко: так же, как и все, упускают важнейшие детали. При чём по закону подлости все упускают ОДНУ и ту же деталь. Получается:

"Изводишь единого слова ради
Тысячи тонн словесной руды"

Только Маяковский у себя изводил, а ищущий- у дригих авторов.
Пример: я сколько-то времени топтался на месте потому, что не мог врубиться в термин "функция возвращает". Смешно? Мне тоже, когда знаешь. И ни один автор этого термина не уточнял. Поразумевалось, что читатель понимает "возвращает" означает "возвращает в то место, откуда вызвана". Привет.

Вот просто прикола ради сходи по последней моей ссылке, и подумай- имеет права, человек тормознуться на приведённых мною строчках или нет?
А кто-то считает этот текст наикрутейшим! Кто-то орёт: документацию в печку! И ведь аргументированно, орёт, самое-то интересное (хотя, он, может, и не прав по сути).

Далее. Я, когда спрашиваю, я не решаюсь переспросить- а при чём собсно здесь процессор?
При чём здесь железо вообще? (Хотя столь много людей говорит именно о железе, что они не могут быть неправы).
Если бы мне сказали: штутдируй Windows. Допустим, загрузчик. Изучай код, как он работает, что куда загружает и в каком порядке. Или планировщик процессов- было бы понятно, это надо.
А тут железо... Я всю жизнь знал, что код это наше всё, что ЕДИНСТВЕННОЕ, что может дать железо, это ресурсы (память и скорость действия процессора). Как следствие- увеличивающееся быстродействие. А тут везде я узнаю, что код это не наше всё, оказывется. Нормально?
Но я не спрашиваю, при чём здесь железо. Я, грешник, попытаюсь как можно меньше его касаться. Хочу лишь сказать: при всей такой НЕРВОЗНОСТИ советы, подобные твоему, да ещё таким тоном данные, кроме отторжения ничего не вызовут.

Либо ткни носом, либо разжуй и положи в рот. Мне можно. Я никогда не спрашивал, как решить задачу. А спрашиваю только тогда, когда нахожу ПРОТИВОРЕЧИЯ (да хоть бы даже в этой теме).Тут надо без расмусоливания сказать: тут Рихтер не прав и всё. И всё! И это здесь было сказано, спасибо.
А пинать туда не зная куда, аргументируя "честное слово, эти труды понятны"... Чё добился- непонятно. Ну, твоё дело.
barmaley57, спасибо, повременим пока. Попробую сам чё-нибудь найти.