Оверлеи

Еще более интересный способ загрузки программы — это оверлейная загруз­ка (over-lay, лежащий сверху) или, как это называли в старой русскоязычной литературе, перекрытие. Смысл оверлея состоит в том, чтобы не загружать программу в память целиком, а разбить ее на несколько модулей и поме­щать их в память по мере необходимости. При этом на одни и те же адреса в различные моменты времени будут отображены разные модули. Отсюда и название потребность в таком способе загрузки появляется, если у нас виртуальное адресное пространство мало, например I Мбайт или даже всего 64 Кбайт (на некоторых машинах с RT-1I бывало и по 48 Кбайт, и многие полезные программы нормально работали!), а программа относительно велика. На со­временных 32-разрядных системах виртуальное адресное пространство обычно измеряется гигабайтами, и большинству программ этого хватает, проблемы с нехваткой можно решать совсем другими способами. Тем не менее, существуют различные системы, даже и 32-разрядные, в которых нет устройства управления памятью, и размер виртуальной памяти не может превышать объема микросхем ОЗУ, установленных на плате. Пример такой системы — упоминавшийся выше транспьютер. Важно подчеркнуть, что, несмотря на определенное сходство между задача­ми, решаемыми механизмом перекрытий и виртуальной адресацией, одно ни в коем случае не является разновидностью другого. При виртуальной ад­ресации мы решаем задачу отображения большого адресного пространства на ограниченную оперативную память. При использовании оверлея мы ре­шаем задачу отображения большого количества объектов в ограниченное адресное пространство. Основная проблема при оверлейной загрузке состоит в следующем: прежде чем ссылаться на оверлейный адрес, мы должны понять, какой из оверлей­ных модулей в данный момент там находится. Для ссылок на функции это просто: вместо точки входа функции мы вызываем некую процедуру, назы­ваемую менеджером перекрытий (overlay manager). Эта процедура знает, какой модуль куда загружен, и при необходимости "подкачивает" то, что загружено не было. Перед каждой ссылкой на оверлейные данные мы должны выполнять аналогичную процедуру, что намного увеличивает и замедляет Программу. Иногда такие действия возлагаются на программиста (Winl6, Mac OS до версии 10 — подробнее управление памятью в этих системах J., иногда — на компилятор (handle pointer в Zortech " C/C++ для MS DOS), но чаше всего с оверлейными данными вообще предпочитают не иметь дела. В таком случае оверлейным является только код. В старых учебниках по программированию и руководствах по операционным системам уделялось много внимания тому, как распределять процедуры между оверлейными модулями. Действительно, загрузка модуля с диска:представляет собой довольно длительный процесс, поэтому хотелось бы ми­нимизировать ее. Для этого нужно, чтобы каждый оверлейный модуль был как можно более самодостаточным. Если это невозможно, стараются выне­сти процедуры, на которые ссылаются из нескольких оверлеев, в отдельный модуль, называемый резидентной частью или резидентным ядром. Это мо­дуль, который всегда находится в памяти и не разделяет свои адреса ни с каким другим оверлеем. Естественно, оверлейный менеджер должен быть частью этого ядра. Каждый оверлейный модуль может быть как абсолютным, так и перемещае­мым. От этого несколько меняется устройство менеджера, по не более того, fin Архитектурах типа i80x86 можно делать оверлейные модули, каждый из ко-;торых адресуется относительно значения базового регистра cs и ссылается на данные, статически размещенные в памяти, относительно постоянного значения регистра ds. Такие модули можно загружать в память с любого адреса, может быть, даже вперемежку с данными. Именно так и ведут себя оверлейные менеджеры компиляторов Borland и Zortech.'3.7.

Дата добавления: 2014-11-25