физическом пространстве и сохраняется возможность работы со стандартными 4-Кбайтными страницами базового режима. Это позволяет довольно эффективно управляться с современными объемами физической памяти компьютера.
Есть и еще один режим, неофициальный, но тоже работающий на всех 32-разрядных процессорах х86, — «нереальный» (unreal), он же «большой реальный» (big real). Он позволяет процессору в реальном режиме обращаться к данным, расположенным в любом месте 4-Гбайтного пространства линейных (и физических) адресов. Этот режим базируется на логике блока сегментации, которая при вычислении линейного адреса во время обращений к памяти пользуется скрытыми программно-недоступными регистрами дескрипторов сегментов. Из этих регистров берется базовый адрес, из них же берется и лимит, который используется схемой защиты. В этих регистрах кэшируются дескрипторы сегментов, загружаемые из памяти во время исполнения инструкций, переопределяющих значения сегментных регистров (CS
, DS
, SS
, ES
, FS
и GS
) в защищенном режиме. По аппаратному сбросу в эти скрытые регистры заносятся «неинтересные» параметры стандартного реального режима, с лимитом 64 Кбайт. В реальном режиме при переопределении сегментных регистров значение базового адреса берется как 16-кратное значение, загружаемое в соответствующий сегментный регистр, а лимит устанавливается в 64 Кбайт. Тем не менее, если в защищенном режиме в сегментный регистр загрузить селектор дескриптора, в котором описан сегмент размером 4 Гбайт с нулевым базовым адресом и возможностью полного доступа на любом уровне привилегий, переключиться в реальный режим и не трогать этот сегментный регистр, то далее процессор будет иметь доступ ко всему этому сегменту в данной модификации реального режима. Однако такая «благодать» распространяется только лишь на доступ к FS
и GS
, которые используются в инструкциях обращений к памяти, снабженных префиксами замены сегмента. Эти сегментные регистры появились только с 32- разрядными процессорами, и никакие традиционные сервисы BIOS (и DOS) их не затрагивают. Остальные сегментные регистры настолько часто используются, что «время жизни» описания большого сегмента в их кэширующих регистрах будет слишком коротким. Программный код, увы, исполняется только из сегмента, которым командует CS, поэтому для него остается лишь первый мегабайт с 64-Кбайтными сегментами. Так что большие программные модули приходится подгружать в эту область по мере надобности, но это можно выполнять довольно быстро пересылками данных из любого места «большого сегмента». Большой реальный режим широко используется менеджерами памяти, а также игровыми DOS-программами, всецело захватывающими ресурсы компьютера.
Итак, самые широкие возможности адресации имеются в защищенном 32-разрядном режиме, наиболее естественном для современных процессоров. В этом режиме может использоваться как плоская, так и сегментная модели памяти. Под плоской (flat) понимается модель, в которой все сегментные регистры указывают на один и тот же сегмент памяти (как правило, начинающийся с нулевого адреса), и его лимит может достигать 4 Гбайт, что позволяет адресовать этот немалый (даже по нынешним меркам) объем памяти без манипуляций сегментными регистрами. Однако при этом теряются все возможности виртуализации памяти на основе сегментов, а также отсутствует сегментная защита. В
12.5.2. Проблемы страничной переадресации
В реальном режиме (при отключенной страничной переадресации) логический адрес, формируемый прикладной программой, совпадает с физическим адресом, фигурирующим на шинах расширения. Тут все просто, правда, в стандартном (а не большом) реальном режиме доступен только первый мегабайт адресов (только устройства в области UMA).
В защищенном режиме в принципе доступно все физическое адресное пространство, но появляются проблемы, связанные с отображением логических адресов на физические. Отображением (поддержкой таблиц переадресации) ведает ОС, приложения могут только узнать карту отображений (получить список физических адресов страниц для какой-то области своей виртуальной памяти). Какие-то области могут в данный момент и не присутствовать в ОЗУ (они могут быть выгруженными на диск). У драйверов устройств возможностей больше — они могут запросить блок памяти с последовательными физическими страницами и потребовать фиксации определенных страниц (запретить их выгрузку из ОЗУ).
При организации прямого доступа к памяти, как по стандартным каналам DMA, так и используя ведущие устройства шин ISA и PCI, возникает проблема пересечения границ страниц. Если приложение хочет выполнить обмен по DMA с областью доступной ей памяти непосредственно, то оно должно запросить у ОС физический адрес, которому соответствует логический адрес предполагаемого буфера обмена. Именно этот физический адрес должен задаваться устройству, выполняющему DMA, при инициализации сеанса обмена (указании начального адреса, длины блока и запуске канала). В каждом сеансе обмена не должна пересекаться граница страницы, которой оперирует блок страничной переадресации, поскольку следующая логическая страница может иметь физическое отображение в произвольном (относительно предыдущей страницы) месте. Чаще всего ОС оперирует страницами по 4 Кбайт, при этом пересылка больших блоков данных ведется «короткими перебежками», между которыми процессор должен выполнять повторную инициализацию DMA. Эта проблема решается усложнением контроллеров DMA — применением «разбросанной записи» в память (scatter write) и «собирающего чтения» памяти (gather read). Контроллеру DMA задается список описателей блоков (начальный адрес и длина). Отработав очередной блок памяти, контроллер переходит к следующему, и так до конца списка. Такие возможности имеет, например, стандартный контроллер PCI IDE (см. п. 9.2.1). Стандартный контроллер DMA имеет и другую «страничную проблему», связанную с реализацией регистров страниц (см. п. 12.4).
Проблема пересечения границ может решаться и иначе, без усложнения контроллера DMA. Для этого в памяти резервируется буфер значительного размера, отображенный на непрерывную область физической памяти, и обмен данными физическое устройство выполняет только с этим буфером. Однако такой буфер рядовое приложение создать не может; он может быть организован лишь драйвером устройства. Приложения могут только получать указатели на этот буфер и обмениваться с ним данными. Таким образом, по пути от приложения к устройству появляется дополнительная «перевалочная база» (буфер драйвера) и дополнительная пересылка данных, что приводит к дополнительным затратам времени.