Проектирование реляционных баз данных. Ковалев А.В - 72 стр.

может иметь много форм. Некоторые очевидные формы зависимости включают прямое мани-
пулирование регистрами и другими аппаратными средствами.
      В-четвертых, если аппаратно зависимый код не может быть полностью исключен, то он
должен быть изолирован в нескольких хорошо локализуемых модулях. Аппаратно-зависимый
код не должен быть распределен по всей системе. Например, можно спрятать аппаратно-
зависимую структуру в программно-задаваемые данные абстрактного типа. Другие модули сис-
темы будут работать с этими данными, а не с аппаратурой, используя набор некоторых функ-
ций. Когда ОС переносится, то изменяются только эти данные и функции, которые ими мани-
пулируют.
      Для легкого переноса ОС при ее разработке должны быть соблюдены следующие
требования:
   • Переносимый язык высокого уровня. Большинство переносимых ОС написано на языке С
      (стандарт ANSI X3.159-1989). Разработчики выбирают С потому, что он стандартизован,
      и потому, что С-компиляторы широко доступны. Ассемблер используется только для тех
      частей системы, которые должны непосредственно взаимодействовать с аппаратурой
      (например, обработчик прерываний) или для частей, которые требуют максимальной
      скорости (например, целочисленная арифметика повышенной точности). Однако непе-
      реносимый код должен быть тщательно изолирован внутри тех компонентов, где он ис-
      пользуется.
   • Изоляция процессора. Некоторые низкоуровневые части ОС должны иметь доступ к про-
      цессорно-зависимым структурам данных и регистрам. Однако код, который делает это,
      должен содержаться в небольших модулях, которые могут быть заменены аналогичными
      модулями для других процессоров.
   • Изоляция платформы. Зависимость от платформы заключается в различиях между рабо-
      чими станциями разных производителей, построенными на одном и том же процессоре
      (например, MIPS R4000). Должен быть введен программный уровень, абстрагирующий
      аппаратуру (кэши, контроллеры прерываний ввода-вывода и т. п.) вместе со слоем низ-
      коуровневых программ таким образом, чтобы высокоуровневый код не нуждался в изме-
      нении при переносе с одной платформы на другую.

      4.6.4. Совместимость

       Одним из аспектов совместимости является способность ОС выполнять программы, на-
писанные для других ОС или для более ранних версий данной операционной системы, а также
для другой аппаратной платформы.
       Необходимо разделять вопросы двоичной совместимости и совместимости на уровне ис-
ходных текстов приложений. Двоичная совместимость достигается в том случае, когда можно
взять исполняемую программу и запустить ее на выполнение на другой ОС. Для этого необхо-
димы: совместимость на уровне команд процессора, совместимость на уровне системных вызо-
вов и даже на уровне библиотечных вызовов, если они являются динамически связываемыми.
       Совместимость на уровне исходных текстов требует наличия соответствующего компи-
лятора в составе программного обеспечения, а также совместимости на уровне библиотек и сис-
темных вызовов. При этом необходима перекомпиляция имеющихся исходных текстов в новый
выполняемый модуль.
       Совместимость на уровне исходных текстов важна в основном для разработчиков при-
ложений, в распоряжении которых эти исходные тексты всегда имеются. Но для конечных
пользователей практическое значение имеет только двоичная совместимость, так как только в
этом случае они могут использовать один и тот же коммерческий продукт, поставляемый в виде
двоичного исполняемого кода, в различных операционных средах и на различных машинах.
       Обладает ли новая ОС двоичной совместимостью или совместимостью исходных тек-

                                               74