книги из ГПНТБ / Королев, Л. Н. Структуры ЭВМ и их математическое обеспечение учебное пособие

более всего повлияет на развитие современной научнотехнической революции.

Говорят, что ЭВМ увеличивают интеллектуальную мощь общества. Развитие систем разделения времени и систем управления в реальном масштабе времени — это тот осязаемый путь, который превращает эти слова в ре­ альность.

Структура ЭВМ четвертого поколения должна отра­ зить требования, выдвигаемые развитием операционных систем, управляющих многообразными режимами ис­ пользования ЭВМ. Основные структурные особенности машин четвертого поколения обеспечивают возможности объединения ЭВМ в многопроцессорные комплексы с раз­ витыми устройствами обмена информацией внутри сис­ темы, дальнейшим развитием методов связи с большим количеством внешних каналов, связи с телефонными и те­ леграфными линиями, прямой связи с источниками дан­ ных, дальнейшим развитием понятия виртуальной па­ мяти и усложнением ее структуры, с дальнейшим разви­ тием способов отображения виртуальной памяти на физическую. Перед конструкторами средств вычислитель­ ной техники возникает задача создания грандиозных ар­ хивов данных и средств визуального отображения и задания информации, а перед программистами-системни- ками — задача организации сложных операционных сис­ тем, организации хранения, поиска и защиты данных и создания программных средств обработки графической информации.

В связи с вышеизложенным ясна роль операционных систем и роль математического программного обеспече­ ния ЭВМ третьего и грядущего четвертого поколения. От развития исследований и разработок в области опе­ рационных систем зависит, как широко и сколь ка­ чественно будут использованы вычислительные мощнос­ ти, объем которых растет по экспоненте.

Как представляется, область прикладной математики, связанная с математическим обеспечением ЭВМ, в нас­ тоящее время вышла на главные рубежи научно-техни­ ческого прогресса, а в этой области операционные системы вышли на первый план. Попробуем остановиться на ос­ новных этапах развития операционных систем, с тем чтобы представить пути их дальнейшего совершенство­ вания.

240

Операционные системы появились еще на однопрог­ раммных машинах, и основное назначение их состояло

втом, чтобы облегчить работу оператора с программами, оставленными на операторный счет, который произво­ дится в отсутствие программиста — создателя програм­ мы. Соответственно возник так называемый пакетный режим счета, режим пропуска заранее заготовленного пакета программ через машину. Язык управления зада­ ниями возник как формализация инструкций оператору, описывающих режим обработки индивидуальной зада­ чи. В операционных системах появились управляющие программы-мониторы, умеющие понимать этот язык и исполнять его директивы без участия оператора.

Качественный скачок в области развития операцион­ ных систем произошел в тот момент, когда структура ЭВМ стала позволять совмещать во времени работу вы­ числителя с работой внешних устройств. Возник режим мультипрограммирования, и возникли новые функции операционных систем, связанные с управлением мульти­ программным режимом, режимом одновременного исполь­ зования нескольких устройств ЭВМ, автоматизировав­ шим труд оператора.

Если однопрограммные пакетные операционные сис­ темы в какой-то мере явились отражением опыта опера­ тора, управляющего последовательным счетом программ, то мультипрограммные операционные системы поставили перед их разработчиками проблемы, не имевшие аналога

вдействиях оператора-человека. У операционных систем появились новые, сложные, логические функции управ­ ления процессами.

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

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

241

четыре режима использования ЭВМ и соответственно четыре типа операционных систем:

—операционные системы, управляющие режимом па­ кетной обработки;

—операционные системы, управляющие режимом дистанционной пакетной обработки;

—операционные системы, управляющие режимом коллективного (коммунального) использования ЭВМ;

—операционные системы, управляющие режимом ре­ ального масштаба времени.

Эти режимы в смысле техники управления имеют много общего, но различаются целевыми функциями.

Целевой функцией пакетного режима является дос­ тижение эффективного использования оборудования, уде­ шевление стоимости затрат на решение программ пакета.

Воценке эффективной дистанционной пакетной об­ работки участвует более сложный критерий, учитываю­ щий, кроме стоимости обработки, еще фактор удобства использования системы человеком для управления хо­ дом вычислений своей задачи.

Врежимах коллективного пользования и реального масштаба времени главное — это время. Управление на­ правлено на то, чтобы минимизировать максимальное

время ожидания ответа пользователем; если речь идет о коллективном доступе, то и на соблюдение заданных ограничений на время обработки.

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

Возникает вопрос: можно ли создать какую-то уни­ версальную операционную систему с автоматически наст­ раиваемой стратегией управления, которая могла бы эффективно и разумно управлять всеми этими системами?

На этот вопрос, наверное, следует ответить отрица­ тельно. С другой стороны, во всех операционных систе­

242

мах есть много общего, есть много универсальных ме­ ханизмов, обеспечивающих выполнение многих однотип­ ных для всех операционных систем функций, и это приводит к мысли о возможности создания некоторого универсального ядра, опираясь на которое далее можно наращивать специализированные функции операционных систем, учитывающих специфику конкретных областей применения ЭВМ.

Такое типовое ядро должно, прежде всего, достав­ лять удобные средства для расширения функций ОС. Предстоит большой объем исследовательских работ, ко­ торые позволят выделить функции ядра, образующие базис операционных систем.

Следует отметить, что попытки создать универсальные операционные системы, пригодные для управления ЭВМ во всех случаях жизни, уже имели место.

Важно отметить, что путь универсализации обычно приводит к дорогой плате как в смысле стоимости и вре­ мени разработки, так и в смысле потери эффективности во всех режимах использования ОС. Примером этому может служить OS/360, которая в ряде применений не­ эффективна (в частности, при попытках ее использова­ ния в системах, оснащенных малыми моделями IBM-360), а в ряде случаев просто непригодна (в частности, в не­ которых системах управления в реальном масштабе времени).

Система генерации, предусмотренная для OS/360, теоретически очень интересная вещь, практически не спа­ сает положения, хотя и весьма полезна для быстрой наст­ ройки операционной системы на конкретный состав обо­ рудования. Это происходит потому, что система генерации основана на некоторых априорных представлениях о режимах и сферах применения аппаратуры и вычисли­ тельных средств. В действительности разнообразие ре­ жимов, определяемых конкретными условиями примене­ ния, никогда не укладывается в «область определения» ОС. Во многих случаях требуемые режимы столь просты, что для их осуществления требуется лишь незначитель­ ная часть всех возможностей, предоставляемых опера­ ционной системой.

На пути разработки многофункциональных универ­ сальных ОС, подобных OS/360, тем не менее достиг­ нуты серьезные успехи, такие системы существуют,

243

и отвергать их практическое и теоретическое значение нельзя.

Есть другой путь, противоположный первому,— это путь создания для каждого конкретного случая приме­ нения ЭВМ «своей» узкоспециализированной ОС. Этот путь допустим, так как дает в ряде случаев эффект, оку­ пающий труд, затраченный на разработку. Недостатки такого подхода очевидны, если речь идет о применении серийных ЭВМ и серийного околомашиниого оборудо­ вания для различных целей.

Очевидно, лучше всего знают, какова должна быть операционная система, каким требованиям она должна удовлетворять и как она должна работать, те, кто не­ посредственно использует ЭВМ в сфере своей конкрет­ ной деятельности. Если предоставить пользователям удобные средства для создания ими изменения операци­ онной системы по своему усмотрению, то это в значитель­ ной степени решило бы проблему эффективного исполь­ зования вычислительных средств в различных сферах уп­ равления и обработки информации.

На протяжении нескольких глав этой книги расска­ зывалось о структуре, архитектуре и математическом обеспечении нескольких отечественных и зарубежных машин.

Этим далеко не исчерпывается то разнообразие в подходе к созданию ЭВМ, которое имеет место в дейст­ вительности. В середине 60-х годов разработчиками ЭВМ была принята простая идея о неразрывности структуры ЭВМ и ее математического обеспечения. И это было по­ нято как раз в тот момент, когда из огромного разнооб­ разия непрерывно изобретаемых языков программиро­ вания выделилось несколько универсальных языков, оказавшихся наиболее привлекательными для широкого

операционных систем как способа наиболее эффективного использования возможностей аппаратуры и экономии времени, труда и квалификации обслуживающего пер­ сонала. Но, несмотря на это, разработчики ЭВМ пред­ лагают машины с новыми внутренними структурными особенностями, в то время как внешний языковый уро­ вень для всех машин приблизительно одинаков: ФОРТРАН, АЛГОЛ-60, КОБОЛ, PL-1, СИМУЛА.

244

Может быть, наступила пора придумать универсаль­ ную архитектуру и структуру ЭВМ, принять их в ка­ честве стандарта и заниматься только усовершенствова­ нием скоростных параметров отдельных элементов этой универсальной, стандартной, для всех одинаковой струк­ туры?

В 1963—1964 гг. появилась система IBM-360, и это ознаменовало вполне определенный положительный от­ вет на заданный вопрос, который дала крупнейшая фир­ ма в области разработки ЭВМ. В 1970 г. та же фирма слегка исправила свое понятие о стандартной архитекту­ ре, выпустив в серию семейство IBM-370, тем самым под­ твердив свое отношение к заданному Еопросу. Но, не­ смотря на это, продолжали развиваться подходы к созда­ нию ЭВМ, значительно отличающиеся от стандарта IBM.

Успешно развивали свои идеи разработчики фирмы

Появилась машина СИМВОЛ, внутренняя организа­ ция которой обратила на себя всеобщее внимание. Чтобы ответить на вопрос об универсальной структуре, который носит отнюдь не риторический характер, позвольте про­ вести некоторое рассуждение общего характера.

Систему ЭВМ+МО можно представить себе состоящей из трех уровней.

Первый уровень — это входные языки, включая сю­ да языки (директивы) связи человека с машиной.

Второй уровень — это архитектура ЭВМ, или вир­ туальная, математическая машина, представленная сво­ ей системой команд, способом организации внутренней и внешней памяти, способом адресации, способом за­ щиты памяти и организацией прерываний.

Наконец, третий уровень — это аппаратура, вклю­ чающая возможности элементной базы, технические па­ раметры запоминающих устройств разных уровней, тех­ нические возможности, возможности линий связи и па­ раметры внешних устройств. Третий уровень — это те кирпичики, из которых можно, вообще говоря, постро­ ить дом любой архитектуры.

Первый, логически самый высокий уровень, отобра­ жается на виртуальную машину программным путем,

245

т. е. путем создания трансляторов и интерпретаторов. Любое задание машине, выраженное на входном языке, обязательно проходит путь трансляции.

Вторая ступень есть отображение виртуальной ма­ шины, архитектуры на аппаратные средства. Это отобра­ жение производится главным образом схемным путем, разработкой жестких связей между аппаратными «кир­ пичиками», разработкой схемных автоматов, управляю­ щих этими заранее запланированными связями между аппаратными элементами. В современных машинах зна­ чительную долю работы в процессе этого отображения виртуальной машины на физическую аппаратуру выпол­ няют программным путем внутренние блоки операцион­ ных систем. Операционные системы тем самым позволяют при одних и тех же аппаратных связях варьировать ха­ рактер и возможности виртуальной машины в достаточ­ но широких пределах. Очевидно, чем элементарнее вир­ туальная машина, тем более трудоемок и сложен про­ цесс отображения с первого уровня на второй. В то же время, как правило, упрощается аппаратная реализа­ ция, т. е. упрощается и становится более эффективным процесс отображения виртуальной машины на физичес­ кую аппаратуру.

Нижний аппаратный уровень развивается по своим собственным законам, и степень его развития определя­ ется достижениями технологии и новыми открытиями, вообще говоря, не связанными с развитием идей двух более высоких уровней системы ЭВМ+МО.

Разработчики ЭВМ должны опираться на этот уро­ вень, как на вещь, заданную априори. Разумеется, хоро­ шие разработчики должны предвидеть и прогнозировать развитие параметров аппаратуры и появление новых возможностей или новых устройств, пригодных для вы­ числительной техники.

С какой-то степенью приближения можно считать параметры аппаратуры заранее заданными. В меньшей степени, но также можно считать, что верхний языковый уровень задан жестко, достаточно жестко.

И вот разработчику, создателю структуры машины, надо решить, куда же поставить уровень виртуальной машины: ближе к аппаратурной земле или ближе к облач­ ному уровню языков. Надо подсчитать интегральный убы­ ток. Упростив виртуальную машину и, следовательно,

24&

упростив аппаратную реализацию, он потеряет в общей системе время на длительную и сложную трансляцию, а также деньги и сроки на разработку сложного матема­ тического обеспечения. Подняв как можно выше уро­ вень виртуальной машины, он выиграет в скорости транляции, но усложнит аппаратную реализацию и скорее всего потеряет в эффективности использования аппарату­ ры, потеряет в скорости выполнения программ. Произ­ вол и разнообразие в выборе положения уровня вирту­ альной машины между этими двумя зафиксированными на некоторый период времени уровнями земли и неба в значительной степени объясняется тем, что нет мето­ дики расчета, позволяющего точно оценить правильность принятия того или иного решения.

На сегодня кажется очевидным, что, если сфера при­ менения ЭВМ такова, что большинство задач, будучи однажды оттранслированы, используются затем много­ кратно, в первую очередь следует заботиться о получе­ нии максимального быстродействия, используя все по­ тенциальные возможности аппаратуры. Очевидно и то, что если характер использования ЭВМ главным образом

jсвязан с однократным решением непрерывного потока задач, то виртуальная машина должна быть как можно ближе подвинута к уровню входных языков высокого уровня. Именно различия в характере использования ЭВМ в тех или иных сферах объясняют, почему бок о бок существуют и развиваются столь различные принципы структурной организации ЭВМ. Поэтому, наряду с раз­ витием направления, заложенного в структурах машин Барроуз, МИР, СИМВОЛ, происходит развитие направ­ ления, отраженного в структурах машин «Атлас», БЭСМ-6, CDC, и развитие промежуточного направления, носителем которого является фирма IBM.

Что же будет дальше? Сольются ли эти направления или будут развиваться достаточно независимо друг от друга?

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

247

так называемых проблемно-ориентированных языков и систем программирования. Например, появился язык для описания дискретных моделей СИМУЛА-67, язык ЛИСП, для описания работы со списочными струк­ турам и диалоговые языки и т. д. Перечисленные выше языки относятся к классу алгоритмических, т. е. таких языков, изобразительные средства которых удобны для точного однозначного описания алгоритмов обработки данных, алгоритмов решения задач.

К классу алгоритмических языков следует отнести и языки нового поколения PL-1, АЛГОЛ-68, в которых определены действия над более сложными элементами, такими, например, как структуры, даны возможности задания параллельных процессов и ветвей. И тем не менее программист, описывающий свою задачу, вынужден на этих языках четко формулировать весь алгоритм ре­ шения задачи.

Как представляется, уже в ближайшем обозримом будущем возникнут системы общения с машиной, прин­ ципиально отличающиеся от методов применения алго­ ритмических языков. Машине не будет предлагаться алгоритм решения, ей будет формулироваться задача, ставиться цель. Способы достижения цели, отыскание необходимого алгоритма будут возлагаться на саму машину.

Переход к подобного рода использованию ЭВМ уже сейчас достаточно хорошо подготовлен. В составе мате­ матического обеспечения любой машины имеются пакеты программ и алгоритмов решения большого числа при­ кладных задач, избавляющие человека от необходимости изобретать и формулировать алгоритм поиска решения. Человеку достаточно знать состав пакета, выбрать нуж­ ную подпрограмму и по определенным правилам записать обращение к ней. Иными словами, от человека требуется в этом случае «поставить» задачу. Например, если зада­ ча сводится к решению системы обыкновенных дифферен­ циальных уравнений, то для того, чтобы решить эту задачу сейчас, надо лишь уметь по определенным прави­ лам выписать эту систему, записать начальные значения, задать требуемую точность, сформулировать пожелания относительно формы выдачи результатов и написать об­ ращение к соответствующей процедуре пакета стандарт­ ных программ.

248

При наличии в машинной библиотеке, достаточно бо­ гатого набора стандартных программ и программ реше­ ния крупных задач уже сейчас программирование алго­ ритма решения комплексной сложной задачи сводится к заданию последовательности обращения к библиотечным подпрограммам или процедурам.

Происходит любопытный процесс. Языки высокго уровня были созданы прежде всего для того, чтобы дать в руки пользователю богатые и удобные изобразитель­ ные средства формулировки алгоритмов обработки дан­ ных. Это открыло широкие возможности быстрого созда­ ния и накопления алгоритмов и программ, которые могут быть включены в библиотеки, вообще говоря, любых машин.

В свою очередь это приводит к тому, что для широкого круга пользователей изобразительные средства задания методов обработки данных в языках играют все меньшую роль по сравнению со средствами задания способа организации задачи в целом, по сравнению с так на­ зываемыми средствами управления ходом решения задачи.

Естественным продолжением этого направления, т. е. направления развития пакета прикладных задач и стан­ дартных библиотечных программ, должно быть появле­ ние нового уровня, новых приемов общения человека с машиной.

Вместо того, чтобы организовывать последовательное (или параллельное) выполнение библиотечных программ, в результате чего должно быть получено решение задачи, пользователю должна быть предоставлена возможность сформулировать содержательный смысл задачи.

Например, вместо того, чтобы выписывать уравне­ ния движения спутника и обращаться к подпрограмме Рунге — Кутта, организовывать решение краевой зада­ чи, пользователь формулирует задачу приблизительно таким образом: «Определить параметры орбиты спут­ ника так, чтобы он обеспечивал устойчивую ретрансля­ цию телевизионных передач в такие-то интервалы вре­ мени на такие-то районы страны».

Система, приспособленная к решению подобного рода задач, должна проанализировать формулу этого зада­ ния, составить план решения, выбрать из библиотеки необходимые подпрограммы, организовать их после­

249'