Добрый день! У меня при изучении архитектуры 8086-64 возник вопрос: зачем в длинном режиме процессора для использования страничной адресации и размере страницы 4кб необходима такая огромная иерархия таблиц - 4 штуки? зацем виртуальный адрес разбивать на 6 частей? Для сравнения, при размере страниц 2мб число таблиц равно трём, а при гигабайтовой странице - вообще 2. В защищённом режиме процессора число таблиц тоже меньше, чем в длинном. к чему такая иерархия? не проще ли было бы сделать одну таблицу, в которой описать все используемые страницы, а для переключения виртуальных пространств просто менять значения регистра cr3? или я чего-то не понимаю? единственная мысль, которая мне приходит в голову - если бы использовалась одна таблица - для неё пришлось бы резервировать слишком много места 2exp(52-32) записей. Ну, сделать 2 таблицы. Но зачем 4?
Quark 3 это наследие защищенного режима, плюс одна новая. 4ГБ еще можно поделить на строници по 4кб. А вот 64 уже много получается. Вот и вводят дополнительное разбиение. 64 бита если побить на два диапозона много. 32 бита получается тое 2^32 записей Побьем на 3 получается 21 бит тожее много. 2милиона сумарный объем если взять дескриптор в 64бит(8байт) получаем что под таблицы понадобиться 2*2^21*8=32мбайта Поделим на 4 получим 16 бит 2^16 это всего 65536 записей 3*2^16*8=1.5мб разницу чувствуешь? А если учесть что обычному приложению нужно отсилы всего пару мегабайт. А тратить по 32 на каждое приложение расточительно. Причем обычно 2мб это кэш формы. разрешение экрана 1280*1024*4. Отсюда хочешь с экономить память ставте меньше разрешение.
Если страница будет большая, то своппить её система будет очень долго. Получается, что приложение превращается в тормоз при рандрмном доступе к своей памяти.
Тут можно выделить несколько взаимосвязанных причин. 1. Тяжкое наследие проклятого прошлого: хочешь-не хочешь, а совместимость с 80386 обеспечивать надо. 2. Страницы малого размера (4 Кбайта) удобны для организации виртуальной памяти, поскольку могут быть быстро вытеснены на диск или загружены в физическую память, однако в крупных приложениях, особенно 64-разрядных, таких страниц может быть очень много. Поэтому желательно предоставлять выбор из мелких и крупных страниц, что Intel и сделала. Как этой возможностью пользуются существующие ОС -- это уже другой вопрос. 3. Быстрое преобразование линейных адресов в физические возможно только в том случае, если вся необходимая информация хранится не в физической памяти, а во внутренних буферах процессора (в TLB). Однако эти буферы не резиновые, и слишком много записей туда не впихнёшь. Значит, здесь тоже нужно балансировать между удобством обмена страницами с файлом подкачки и количеством страниц. 4. Наконец, "железная" проблема. Аппаратура, связанная с преобразованием адресов в 32- и 64-разрядных режимах, должна быть по возможности общей, чтобы в процессорах было как можно меньше "лишних деталей". Поэтому в 64-разрядном режиме приходится опираться на аппаратуру, изначально рассчитанную под 32-разрядный режим (в частности, это TLB).
Пасиб. Получается что я предполагал почти правильно. Ещё вопрос - как тогда происхожит перекючение адресных пространств при многозадачности? Для каждой задачи создавать свою иерархию страниц и менять значение регистра cr3?
