Чтение онлайн

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

Приложение к "Принципам действия Системы 3GO", написанное Джерри Блау, я считаю лучшим из всех когда-либо виденных мною руководств. В этом приложении очень точно и тщательно описываются пределы совместимости Системы 360, указывается, к чему следует стремиться, и перечисляются те области внешнего окружения, где архитектура умышленно хранит молчание и где результаты, полученные на разных моделях, могут отличаться друг от друга, где один экземпляр данной модели может отличаться от другого или где, наконец, система может отличаться от себя самой после каких-то технологических изменений. Авторы руководств должны стремиться именно к такому уровню точности, они обязаны определять то, чего нельзя делать, столь же тщательно, как и то, что можно.

Формальные описания

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

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

Старая пословица предупреждает: "Никогда не выходи в море с двумя хронометрами: бери один или три". Ее вполне можно отнести и к проблеме текстовых и формальных описаний. Если у вас есть и то, и другое, то одно должно быть стандартом, а второе - производным описанием, что следует указать ясно. В качестве исходного стандарта можно выбрать любое из них. Алгол-68 имеет в качестве стандарта формальное описание и, кроме того, поясняющее текстовое описание. Стандартное описание PL/I дано текстом, а формальное описание - как производное. Система 360 также имеет текстовое описание в качестве стандарта и рядом - производное формальное описание.

Существует множество способов представления формальных описаний. Бэкусова - Наурова форма (БНФ), разработанная для описания языков, широко освещена в литературе2). Формальное описание PL/I использует новую систему обозначении абстрактного синтаксиса, и она адекватно описана3). Язык APL, разработанный Айверсоном, применялся для описания машин, в частности, IBM-70904) и Системы 3605).

Белл и Ныоэлл предложили новую систему для описания конфигураций и архитектуры машин и проиллюстрировали ее на примере нескольких машин, включая PDP-8 фирмы DEC6), IBM-70906) и Системы 3607).

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

Не только формальное описание является реализацией, но и реализация может служить формальным описанием. Именно этот принцип использовался при создании первых совместимых ЭВМ. Новая машина должна соответствовать старой. Какие-то места в руководстве непонятны? "Спросите машину!". Нужно было разработать тестовую программу, определяющую поведение старой машины, и добиться того, чтобы новая машина проходила через этот тест.

Программы-имитаторы аппаратуры или математического обеспечения могут использоваться точно таким же образом. Это реализация; она работает. Поэтому все вопросы описания можно разрешить путем ее проверки.

Использование реализации в качестве описания имеет некоторые преимущества. Все вопросы разрешаются однозначно посредством эксперимента. Дискуссии не нужны, потому что ответы получаются быстро. Ответы всегда точны в той степени, которая нужна, ц они по определению верны. Но, кроме преимуществ, такой подход имеет и очень много недостатков. Реализация может вызвать переопределение даже внешних спецификаций. Ошибка в синтаксисе в реализации приводит к любому результату; в "чистой" системе этот результат является лишь указанием на некорректность и ничем больше. В "неряшливой" системе могут появиться самые разнообразные побочные эффекты, которые могут быть использованы программистами. Когда мы предприняли эмуляцию ЭВМ IBM-1401 на Системе 360, то обнаружилось около 30 различных "курьезов", или побочных эффектов, вызываемых, предположительно, ошибочными операциями, которые, однако, стали широко использоваться и должны теперь рассматриваться как часть описания. Реализация, выступающая в качестве описания, предлагает избыточные определения; она говорит не только о том, что машина должна делать, но, в значительной степени, и о том, как она это должна делать.

Кроме того, реализация будет иногда давать неожиданные и незапланированные ответы на трудные вопросы, это описание de facto оказывается неэлегантным в таких конкретных местах как раз потому, что они в свое время не были продуманы. Их воспроизведение в другой реализации может дорого обойтись. Например, некоторые машины не полностью очищают регистр множимого после умножения. Явление это по своей природе - часть фактического описания, однако его воспроизведение может помешать использованию более быстрого алгоритма умножения.

Наконец, использование реализации в качестве формального описания таит в себе опасную возможность перепутать, что именно является стандартом:

текстовое описание или формальное. Это особенно справедливо в отношении программных имитаторов;

Кроме того, нельзя вносить модификации в реализацию, пока она служит стандартом.

Прямое внесение

В распоряжении архитектора систем математического обеспечения есть превосходный метод распространения и внесения определений. Он особенно полезен для установления, если не семантики, то синтаксиса межмодульных сопряжении. Заключается этот метод в задании описания передаваемых параметров или совместно используемой памяти, и в требований, чтобы реализация включала данное описание через операции периода компиляции (макрокоманды или % INCLUDE в PL/I). Кроме того, если обращение ко всему сопряжению осуществляется только по символическим именам, то описание можно изменить путем добавления или введения новых переменных только ретрансляцией используемой программы без ее изменения.

Конференции и разбирательства

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

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

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

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

Решения, принимаемые на еженедельных совещаниях, дают быстрый результат и не тормозят работу. Если кто-либо ими совершенно неудовлетворен, он может нeмeд^eннo апеллировать к руководителю проекта, но такое случается крайне редко.