Комментарии 13
Так плохо, что писать подробный разбор и не хочется.
Для начала неплохо бы сделать вычитку и поправить все опечатки: куча несопряженных окончаний.
Если мы говорим о том, что выполняет процессор, то это код, а не текст. Тут же не про машину Тьюринга написано.
Стоило бы упомянуть про large pages, которые не 4К размером.
Во всей статье ни разу не упоминается TLB (!), да и вообще описание работы таблицы преобразования виртуального адреса в физический сделано из рук вон плохо, такое ощущение, что автор хотел похвастаться знанием алгоритма BOR, который здесь не в дугу на самом деле.
Ну и упоминание про плохой стиль использования goto в машинном коде - REALLY?! Ну-ка, ну-ка, напишите мне что-нибудь машинное сложнее "Hello world!" без команды jmp или переходов по условию.
Благодарю за фидбэк.
Грамматику и синтаксис поправлю.
"Если мы говорим о том, что выполняет процессор, то это код, а не текст. Тут же не про машину Тьюринга написано.", это уже формализм идет, спасибо за замечание,однако данные понятия очень часто смешивают даже в профессиональной среде.
"Стоило бы упомянуть про large pages, которые не 4К размером.", решил не упоминать по причине того,что статья и так получилась немного перегружена, так если еще кучу определений вводить,то статья еще сильнее разрастётся.
"Во всей статье ни разу не упоминается TLB (!), да и вообще описание работы таблицы преобразования виртуального адреса в физический сделано из рук вон плохо, такое ощущение, что автор хотел похвастаться знанием алгоритма BOR, который здесь не в дугу на самом деле.", согласен, нужно дать мотивацию использования BOR. Однако упомянул для того,чтобы показать как работает виртуальное отображение, для тех кто не знает,будет полезно его вообще встретить в жизни, а также практическое использование BOR-а запомнить. Про TLB нужно упомянуть было, поправлю. И про преобразоаание адреса: это лишь одно из приближений,которого будет достаточно на первое время или ответом на собеседовании.
"Ну и упоминание про плохой стиль использования goto в машинном коде - REALLY?! Ну-ка, ну-ка, напишите мне что-нибудь машинное сложнее "Hello world!" без команды jmp или переходов по условию.", согласен,нужно упомянуть,что есть исключения. Но у меня есть возражение, в том же C++ для обратной совместимости с Си разрешено много конструкций. Однако это не значит,что нужно писать код, используя их, где-то без них не обойтись, когда пртходиться с низкоуровневыми сущностями работать, однако чаще всего goto не требуется,да и на это и существуют код стайлы.
Тут не в кодстайле дело, а в вашей неудачной формулировке. В статье написано:
Instruction pointer передвигается либо за следующей инструкцией, либо куда-то прыгает. Что может заставить перепрыгнуть данный указатель в другую строчку программы:
Использовали goto (много где по код стайлам не рекомендовано);
Я тоже не сразу вдуплил, и мне вообще показалось, будто у вас процессор вместо машинного кода перелопачивает непосредственно сырые сишные исходники (см. счетчик команд вместо адреса следующей машинной инструкции содержит указатель на какую-то «строчку»). Это же бездушная машина, она с числами работает, а не с текстом со строчками.
Такие низкоуровневые концепции удачнее, КМК, хотя бы с псевдо-ассемблером объяснять (смотрите, вот сишный код → а вот результат компиляции и тут уже все наши джампы).
И добавлю, про goto я сказал: "много где по код стайлам не рекомендовано". А про то что "это плохо и никогда не используйте" даже речи и не шло
Как могли увидеть в диалогах выше виртуальная память решает куча проблем: программист не должен заботиться куда выделять память, ведь как в четвёртом сообщении программист ошибся всего‑лишь на один символ и написал в конце 08, а не 80, как сказала ОС. И заметим, что ОС ничего не сделала! Не предупредила, не убила программу. Следующая проблема — памятью пользуется не только наша программа, но и другие.
GPF в PM такой:
внутри страницы понадобиться 12 бит
сколько вообще адресов поместиться в одну страницу
для хранение такой таблицы понадобиться
ещё один адрес страницы, получиться уже
непонятно где находиться реализация
Что храниться в виртуальной памяти
-тся, зумеры блин
ob2AphemlwY у винды так чуть дополню
Строго говоря диалог на кдпв (практически) никакого отношения к виртуальнсти памяти не имеет.
В первой части грустного диалога описаны теоретические мытарства без менеджера памяти (условного malloc/new). Который мало того, что держит под капотом кухню для выделения памяти всяким там векторам и интам, никогда* не ходит к операционке за памятью для единичных выделений, запрашивая сразу крупные блоки из которых потом сам нарезает что нужно, так ещё совершенно* безразличен к тому, виртуальные ли там адреса в куче, иль физические, да и порою к тому есть ли вообще этажом ниже какая-либо ос (ардуинщики не дадут соврать)
Факап второй части связан с отсутствием разграничения доступа к памяти. Механизмы которого никак* на виртуализацию не завязаны. Может быть как разграничение без виртуализации, так и виртуализация без разграничения.
(*) почти
Благодарю за замечания, они все по делу, однако в данном кдпв я специально сделал такие допущения, чтобы как-то наглядно показать хотя бы в первом приближении мотивацию виртуальной памяти. Можно было сделать лучше? Да, конечно, однако у меня в голову лучше идея не пришла. Если можете предложить, то буду только рад и поправлю данный диалог на более корректный
На картинку котика можно поместить. Он тоже к виртуальной памяти не относится, зато милый :)
А если серьезно, то виртуальная память с точки зрения прикладного программиста решает по сути три задачи:
1) Предоставление больших непрерывных блоков (когда свободной памяти в системе 2GB, но четырьмя кусками по 512MB, а нужен буфер в 1GB). Нет необходимости самостоятельно алгоритмически заморачиваться фрагментацией.
2) Отсутствие заботы о том, что память может закончиться (привет свапу). В подавляющем большинстве реального кода обработчиками std::bad_alloc никто не заморачивается.
3) Работа с не-памятью как с памятью: есть какой-то громадный файл в котором нужно что-то поискать - мапим его на память и работаем, как будто прочитали и загрузили. а уж что там с диска подтянуть и когда лишнее освободить - пусть ОС разбирается. Это, кстати, пожалуй единственный случай, когда прикладной программист осознанно и явно (хоть и через прослойку ОС, ессно) взаимодействует с подсистемой виртуальной памяти. Остальные от него просто прозрачно скрыты.
Остальные плюшки типа обеспечения постоянства адресов от прикладного программиста надежно скрыты под капотом.
Введение в память, мотивация виртуальной, отображение между физической и виртуальной