Если целевой компьютер новый, то для него необходим логический эмулятор. Это даёт аппарат для отладки задолго до того, как целевая машина будет в наличии. Что столь же важно, даже тогда, когда становится доступной целевая машина, имеется доступ кнадёжномусредству для отладки.
Надёжное— не то же самое, чтоточное . Эмулятор неизбежно в каком-либо отношении будет отступать от верной и точной реализации архитектуры новой машины. Но это будетодна и та жереализация и сегодня, и завтра, чего не скажешь о новой аппаратной части.
В наше время мы привыкли к тому, что аппаратная часть компьютера большую часть времени работает без сбоев. Если только разработчик прикладной программы не замечает, что система неодинаково ведёт себя при разных идентичных прогонах программы, ему правильнее всего поискать ошибки в своём коде, а не в технике.
Этот опыт, однако, сослужил плохую службу при программировании новой машины. Лабораторные разработки, предварительные или ранние выпуски компьютеровнеработают должным образом,неработают надёжно инеостаются неизменными день ото дня. По мере обнаружения ошибок технические изменения производятся во всех экземплярах машины, включая используемый группой программистов. Такая неустойчивость основания достаточно неприятна. Отказы аппаратуры, обычно скачкообразные, ещё хуже. И хуже всего неопределённость, лишающая стимула старательно копаться в своём коде в поисках ошибки — её может там вовсе не быть. Поэтому надёжный эмулятор на зрелой машине остаётся полезным значительно дольше, чем можно было предположить.
Машины для компилятора и ассемблера.По тем же причинам требуются компиляторы и ассемблеры, работающие на надёжных машинах, но компилирующие объектный код для целевой системы. Затем можно начать его отладку на эмуляторе.
При программировании на языках высокого уровня значительную часть отладки можно произвести при компиляции для вспомогательной машины и тестировании результирующей программы, прежде чем отлаживать программу для целевой машины. Этим достигается производительность непосредственного исполнения, а не эмуляции, в сочетании с надёжностью стабильной машины.
Библиотеки программ и учёт.Очень успешным и важным применением вспомогательной машины в программе разработки OS/360 была поддержка библиотек программ. Система, разработанная под руководством У. Р. Кроули (W. R. Crowley), состояла из двух соединённых вместе машин 7010 и общей дисковой базой данных. На 7010 поддерживался также ассемблер для S/360. В этой библиотеке хранился весь протестированный или находящийся в процессе тестирования код, как исходный, так и ассемблированные загрузочные модули. На практике библиотека была разбита на подбиблиотеки с различными правами доступа.
Прежде всего, у каждой группы или программиста была область для хранения экземпляров программ, контрольных примеров и окружения, которое требовалось для тестирования компонентов. На этойплощадке для игрне было никаких ограничений на действия с собственными программами.
Когда компонент программиста был готов к включению в более крупную часть, его экземпляр передавался менеджеру этой более крупной системы, который помещал его вподбиблиотеку системной интеграции . Теперь автор не мог его изменить без разрешения менеджера интеграции. Когда система собиралась воедино, этот менеджер проводил все виды системного тестирования, выявляя ошибки и получая исправления.
Через некоторое время системная версия была готова для более широкого использования. Тогда она перемещалась вподбиблиотеку текущей версии . Этот экземпляр был священным, и доступ к нему разрешался только для исправления разрушительных ошибок.
Его можно было использовать для интегрирования и тестирования всех новых версий модулей. Программный каталог на машине 7010 отслеживал все версии каждого модуля, его состояние, местонахождение и изменения.
Здесь важны два обстоятельства. Первое — этоконтроль , означающий, что экземпляры программ принадлежат менеджерам, и только они могут санкционировать их изменение. Второе —формальное разделениеиперемещениес площадки для игр к интеграции и выпуску новой версии.
По моему мнению, это было одним из лучших решений в программе OS/360. Эта часть технологии управления была независимо разработана для нескольких крупных программных проектов, в том числе в Bell Labs, ICL и Кембриджском университете. [50] Она применима как к программам, так и к документации. Это — неоценимая технология.
Программные инструменты.По мере появления новых технологий отладки старые теряют значение, но не исчезают. По-прежнему необходимы дампы памяти, редакторы исходного текста, дампы мгновенного состояния, даже трассировки.
Аналогичным образом, требуется полный набор утилит для загрузки колод перфокарт на диски, копирования магнитных лент, печати файлов, изменения каталогов. Если инструментальщика проекта назначить на достаточно ранней стадии, то все это может быть сделано сразу и находиться в готовности к моменту надобности.
Система документации.Из всех инструментов больше всего труда может сберечь компьютеризированная система редактирования текста, действующая на надёжной машине. Наша система, разработанная Дж. У. Франклином (J. W. Franklin), была очень удобна. Я думаю, без неё руководства по OS/360 появились бы значительно позднее и оказались бы более запутанными. Есть люди, которые станут утверждать, что двухметровая полка руководств по OS/360 является следствием недержания речи, и сама её объёмистость являет собой новый тип непостижимости. И доля правды в этом есть.
Но у меня есть два возражения. Во-первых, хотя документация по OS/360 и ошеломляет размерами, план её изучения тщательно изложен. Если использовать его избирательно, то чаще всего можно не обращать внимания на большую часть всей массы. Документацию по OS/360 нужно рассматривать как библиотеку или энциклопедию, а не материал для обязательного чтения.
Во-вторых, это гораздо лучше, чем крайняя недостаточность документации, характерная для большинства систем программирования. Я охотно соглашусь, тем не менее, что в некоторых местах текст можно было значительно улучшить, и результатом лучшего описания стал бы меньший объём. Некоторые части (например, «Концепции и средства») сейчас очень хорошо написаны.
Эмулятор производительности.Лучше его иметь. Разработайте его «снаружи внутрь», как описано в следующей главе. Используйте одинаковое проектирование сверху вниз для эмулятора производительности, эмулятора логики и самого продукта. Начните работу с ним как можно раньше. Прислушайтесь к тому, что он вам скажет.
Языки высокого уровня и интерактивное программирование
Сегодня два важнейших инструмента системного программирования — это те, которые не использовались при разработке OS/360 почти десятилетие назад. Они до сих пор не очень широко используются, но все указывает на их мощь и применимость. Это: а) языки высокого уровня и б) интерактивное программирование. Я убеждён, что только инертность и лень препятствует повсеместному принятию этих инструментов, технические трудности более не являются извинениями.
Языки высокого уровня.Главные основания для использования языков высокого уровня — это производительность и скорость отладки. Производительность мы обсуждали раньше (глава 8). Имеющиеся данные, хотя и немногочисленные, указывают на многократный рост, а не на увеличение на несколько процентов.