Учитывая 64-битные системы с 32-битным кодом, разве все 32-битные приложения не должны обязательно использовать одни и те же 4 ГБ ОЗУ?

Question

ПРИНЯТЬ АРХИТЕКТУРУ x86-64, ОЗУ> 4 ГБ И 64-разрядную WINDOWS 10

Учитывая, что любая ячейка памяти, используемая 32-разрядным совместимым приложением, может адресовать ячейки памяти только в пределах первого 4 ГБ ОЗУ (4 байтовых адреса) не означает, что каждое 32-битное приложение должно работать на тех же 4 ГБ ОЗУ в 64-битной системе с более чем 4 ГБ ОЗУ. Если есть какая-то схема, позволяющая сделать так, чтобы одни и те же 32-битные ячейки памяти отображались в разные 64-битные ячейки памяти, чтобы обеспечить использование более 4 ГБ ОЗУ коллективными 32-битными приложениями (т.е. сопоставление разных разделов ОЗУ для 4 ГБ адресуемой памяти в каждом 32-битное приложение, например, при 8 ГБ общей оперативной памяти одно приложение занимает первые 4 ГБ, а другое - следующие 4 ГБ, отображая 32-битные адреса в разные разделы в 8 ГБ), как 32-битные приложения будут взаимодействовать друг с другом по такой схеме ( данные эквивалентные адреса могут указывать на разные ячейки памяти)?

Просто: как 32-битный код может использовать более 4 ГБ памяти на 64-битном компьютере, и разве все 32-битные приложения не должны совместно использовать первые 4 ГБ памяти?

Answer 1

Если есть какая-то схема, позволяющая сделать так, чтобы одни и те же 32-битные ячейки памяти отображались в разные 64-битные ячейки памяти, чтобы позволить использовать более 4 ГБ ОЗУ коллективными 32-битными приложениями

Это именно то, что происходит, да.

как 32-битные приложения будут взаимодействовать друг с другом по такой схеме

Очевидно, не через указатели. Попробуйте написать два 32-битных приложения под 32-битной ОС, выделяя память в одном и пытаясь прочитать ее из другого, и как только вы попытаетесь разыменовать указатель в другом приложении, вы получите sh с нарушением доступа.

В ОС защищенного режима каждое приложение имеет доступ только к тем страницам, которые оно отображает в рамках своего собственного процесса, и поэтому тот факт, что каждое приложение видит свое 64-битное адресное пространство со своими 32-битными битовый адрес ничего не меняет, у них все еще нет доступа к памяти другого процесса.

Если вы действительно запрашиваете IP C методы (ie, способы взаимодействия между процессами) , они широко разнообразны и зависят от ОС, от общей памяти (именованные файлы с отображением памяти, поддерживаемые вашим файлом подкачки), сокетов, именованных каналов, именованных почтовых ящиков, именованных мьютексов (если вы используете синхронизацию), файлов общих дисков, окон сообщения, et c.

Answer 2

Виртуальная память решает проблему, позволяющую сопоставить несколько идентичных адресных пространств с разной физической памятью.

32-разрядные процессы используют 32-разрядные виртуальные адреса, но ОС по-прежнему использует 64- таблицы битовых страниц, которые отображают эти виртуальные адреса в любое место в 52-битном физическом адресном пространстве.

(Реальные процессоры обычно имеют меньшее физическое адресное пространство, чем это, но это тот же размер, независимо от того, какой подрежим длинный режим, в котором они находятся. См. Почему в 64-битном виртуальном адресе длина 4 бита (длина 48 бит) по сравнению с физическим адресом (длина 52 бита)? Подробнее см. и диаграмму страницы x86-64 table)

Таблицы страниц по-прежнему четырехуровневые, я думаю, с нулевым расширением 32-битных адресов до 64-битных. (Тот же каталог страниц верхнего уровня используется 64-битным ядром после прерывания или инструкции sysenter, поэтому 32-битные процессы не будут использовать меньше уровней таблиц страниц. Но все их адреса имеют те же самые высокие 16 бит, поэтому аппаратное обеспечение обхода страниц может легко кэшировать PDE верхнего уровня и одну из четырех записей на уровне ниже.)