Текст книги "«ВОСХОД» программиста"

«Если это так, то это так».

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

Еще во время моей учебы в школе отец обучал меня вождению автомобиля, стрельбе из пистолета и многому другому. Мы часто говорили с ним о литературе, например о Чехове, Толстом, Тургеневе, Гоголе, Шукшине. Обсуждали Апдайка, Азимова, Джека Лондона, Уэллса, Ремарка, Драйзера. Он очень любил Есенина и Пушкина и не раз их цитировал. До сих пор в моей жизни не было большей потери, чем смерть отца. Только когда он ушел, я осознал всю ее величину. И до сих пор мне не хватает его, хочется поговорить, спросить, поделиться с ним мыслями, узнать его мнение. Но увы…

Теперь о маме. Сидоренко Галина Александровна, украинка, родилась и закончила школу в г. Славянске Донецкой области. Тот факт, что она выбрала Харьковский авиационный институт и поступила в него, совсем не удивителен: о ее отце, моем деде, я уже рассказывал. Очевидно его влияние на дочь, да и гены, видимо, сыграли определенную роль. Моя мама пошла в своего отца: она умный, разносторонний человек и настоящий инженер. Пройдя путь от простого инженера до заместителя главного конструктора, мама удостоена медали «За трудовое отличие». Это редкость: инженеров в СССР редко награждали, а ее наградили. У меня, например, таких наград нет.

Не раз замечал, что мою маму люди уважали именно за ее ум.

1956 год, после окончания ХАИ

Многие годы после окончания института она занималась самолетами в КБ Яковлева, работала в группе крыла, в частности, занималась вопросами точной установки крыла на самолет. В дальнейшем, удовлетворяя собственные профессиональные интересы, мама перешла на работу, связанную с конструированием различных установок и приборов.

1978 год, конструктор радиолокационных устройств для самолета КБ Антонова АН-72. Впоследствии – заместитель главного конструктора.

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

2013 год, пенсионер, ветеран труда

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

Мама опубликовала книгу под названием «Память». В ней много интересного о жизни времен ее молодости, более поздних лет, и конечно же, о моем отце. Прожили они вместе более 60 лет. (Отец ушел из жизни в 2016-м.)

Вернемся в МАИ. Не могу не выразить почтения 301-й кафедре и ее заведующему в те времена академику Петрову Борису Николаевичу. Очевидно, что программа обучения на кафедре – это его достижение. И что особенно важно для меня, так это то, что наряду с гироскопами, электрическими машинами, теорией вероятности, теорией автоматического регулирования и другими курсами в программе присутствовали курсы по ЭВМ. Целый год нам читали ВУДД и ВУНД, то есть цифровые и аналоговые ЭВМ! Мне кажется, в те далекие 70-е это было настоящим предвидением ученого. В отличие от многих, академик Петров в своей оценке значимости компьютеров не ошибался.

Компактный накопитель на магнитном барабане, применявшийся в военном компьютере Sage

В курсе ВУДД мне запомнились память на магнитных дисках и барабанах и не «зашедший» мне ALGOL. До сих пор помню собственный рисунок в конспекте, иллюстрирующий устройство внешней памяти на магнитном барабане. Главный плюс барабана по сравнению с магнитным диском в том, что его головки чтения-записи неподвижны.

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

Недостатком барабанов была их более низкая емкость по сравнению с магнитными дисками. Жаль, что их производство свернули в начале 70-х…

Может, это ошибка?

Характерными накопителями на магнитных барабанах последнего поколения были накопители, применявшиеся в компьютерах Sperry Rand Univac и IBM System/360. Sperry Rand Univac – это популярные компьютеры для научно-технических расчетов. Как-то читал об этих компьютерах и, кажется, на курсе в МАИ о них упоминали.

В барабанах для Univac использовалось 880(!) головок чтения/записи. Их неподвижность обеспечивала среднее время доступа к данным 4,25 миллисекунды. Магнитный барабан вращался со скоростью 7200 оборотов в минуту. Скорость 7200 оборотов в минуту выглядит вполне приличной даже для современных жестких дисков, а величина времени доступа схожа с параметрами серверных дисков недавнего прошлого. Для сравнения, жесткие диски IBM 3330 для IBM System/370 уже в 70-е годы имели емкость 100 Мбайт (у нас аналог появился в 80-е), но время доступа к данным – целых 30 миллисекунд. Вот так, 4 и 30 миллисекунд! Накопители были и на магнитных барабанах IBM 2303 и 2301. В устройстве IBM 2303 было также 800 дорожек и емкость порядка 4 Мбайт на накопитель. Для сравнения, типичный жесткий диск 60-х в США имел емкость всего 7,25 Мбайт. В 70-е годы упомянутые магнитные барабаны были вытеснены имеющими ту же скорость передачи, но втрое большую емкость жесткими дисками IBM 2305, но с фиксированными головками на дорожку.

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

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

И никаких программ!

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

Затем наступил самый интересный момент – исследование модели. Различные условия работы смоделированного автопилота реализовывались подачей внешних возмущений в виде электрических импульсов. По виду и величине импульсов на выходе модели можно было судить о работе автопилота. Как же я был поражен, когда подав сигнал, соответствующий боковому порыву ветра при отработке выхода автопилота из бокового крена, увидел фактически катастрофу. Да, именно катастрофу! Автопилот не справлялся, крен увеличивался в колебаниях относительно первоначального крена и в конце концов самолет лег на крыло, а это конец. Некоторое время я находился в ступоре. Схватив методичку я начал читать комментарии по интерпретации результатов. Все точно: для ТУ-130 крен 30 градусов был критичным. Как такое вообще может быть? Ведь это же пассажирский самолет!

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

АВМ были широко распространены в 60-70-х годах. Читал, что именно аналоговые компьютеры сыграли очень важную роль в программе «Аполлон», позволив сымитировать систему управления космическими аппаратами и динамику их поведения. Однако позднее они стали уступать по распространенности цифровым ЭВМ. Возможно, это тоже ошибка. Конечно, точность вычислений на аналоговых ЭВМ ниже, чем на цифровых, но скорость выше. И программирования как такового не требуется.

У аналоговых компьютеров есть явные недостатки: дрейф и смещения нуля операционного усилителя, разбалансировка компонентов схемы (например, изменение сопротивления элементов от жары или холода), а также от других традиционных неисправностей в аналоговых схемах. Однако какая эффективность при решении задач, связанных с дифференциальными уравнениями! Кстати, по мнению некоторых специалистов, аналоговые ЭВМ еще могут вернуться, особенно в связи с улучшением элементной базы. И если это произойдет, я буду рад.

Таким образом, к началу работы в НИИ «Восход» в области ЭВМ я был все-таки не совсем невежественным, но мой опыт взаимодействия с ними вряд ли можно назвать большим и серьезным. А про IBM 360 я практически вообще ничего не знал.

Переход в программисты

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

Забегая вперед скажу, что зря я радовался, получив от начальника «добро»: пользы от этого курса не было никакой. Назывался он «Язык Ассемблер» и, соответственно, давал некое знакомство с языком. Но уже скоро я понял, насколько он был, мягко говоря, бесполезным. Приведу для иллюстрации программу курса.

Материалы XXV съезда КПСС – 12 час.

Архитектура и система команд в ЕС-ЭВМ – 58 час.

Программирование на языке Ассемблер – 64 час.

Введение в программу и подпрограмму ОС – 14 час.

Особенно трогательно выглядят 12 часов, отведенные на «Материалы XXV съезда КПСС». (Сразу же возникают ассоциации с учением «чучхе», хотя мы, вроде, и не Северная Корея.)

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

Нужно было написать программу на Ассемблере, реализующую полученное задание. При этом было оговорено, поскольку курс не был привязан к транслятору (и уж тем более к какой-то операционной системе), то достаточно представить листинг транслятора, а исполнение кода не требовалось. Более того, ввод параметров и вывод результатов было предложено имитировать, например, вызовом svc.

Для тех, кто знаком с операционными системами, это звучит смешно. Самое интересное, что интуитивно я чувствовал в этом некую профанацию.

Дальше возникли проблемы. Все ЭВМ в НИИ «Восход» в то время были сосредоточены на одной территории, именно на той, которая находится у метро «Семеновская». Для доступа к ним нужно было получить «машинное время». («Машинное время» – это действительно какое-то количество часов, которые выделялись подразделению для работы на конкретной ЭВМ в режиме коллективного доступа.) Моему подразделению технических средств защиты время не выделялось никогда.

Более того, я написал свой код на бумаге и даже не представлял себе, как его ввести в ЭВМ и получить листинг транслятора. Спросить об этом (а также по поводу имитации ввода и вывода) у коллег из подразделения программных средств защиты я постеснялся, – не хотелось выглядеть идиотом. Да и отношения между моим руководством и руководителем подразделения программных средств защиты сложились не самые дружественные – из-за пренебрежительного отношения второго к первому.

Однако в подразделении программистов трудился мой знакомый по баскетбольной площадке Юрий Сальников, который не отказался помочь. Но выглядело это так: он забрал мой листок с текстом программы и… вернул уже листинг транслятора, сопроводив его не очень внятными комментариями по поводу svc. Задание, то есть листинг, я сдал преподавателю, взамен получив справку об окончании курса.

И что? – Полное неудовлетворение и тоска.

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

Наверное, настало время рассказать немного о системе. Заказчиком ее был Совет Министров СССР, назначение – «управление народным хозяйством страны». Хотя, с учетом моего сегодняшнего моего опыта в ИТ, правильнее сформулировать ее назначение как предоставление информации для принятия решений по управлению народным хозяйством.

Для реализации были разработаны рабочие места – пользовательские и технологические, обеспечивающие функции по управлению или обеспечению работы системы. Одним из таких технологических рабочих мест было рабочее место ССН – службы специального назначения, на котором сотрудник ССН вершил свои секретные дела. Сама система уже была размещена в специально выстроенном высотном здании на проспекте Вернадского. Она состояла из двух (впоследствии трех) двухмашинных комплексов ЕС-ЭВМ 1030 и упомянутых рабочих мест. Рабочее место ССН являло собой электрическую пишущую машинку (самый простой терминал) в отдельном помещении.

Сначала на этом рабочем месте дежурили разработчики из подразделения программных средств защиты. Как я узнал впоследствии, никаких «событий» на нем не происходило. Тем не менее дежурить нужно было круглые сутки и в выходные, поэтому сначала на вахту заступили молодые специалисты этого подразделения, а затем и моего.

«Командировку» в соседнее подразделение я воспринял с большим оптимизмом (как потом оказалось, преждевременным), в отличие от нашего руководителя, у которого она вызвала вполне понятные возражения. Дежурство выглядело так: две смены – с 8:00 до 20:00 и с 20:00 до 8:00. Начиналось с планерки, на которой строго проверялось присутствие всех дежурных, затем главный дежурный коротко сообщал о текущем состоянии ВС (Вычислительная Система на базе двухмашинного комплекса), после чего все расходились по своим рабочим местам.

Первое дежурство я воспринял с большим энтузиазмом, думая, что наконец-то начну разбираться в устройстве системы. Однако с каждым новым дежурством оптимизм угасал. Как правило, на планерке я слышал одну и ту же фразу: «ВС-1 на профилактике, ВС-2 не работает». (Обычно доклад подразделялся на две части – по каждому двухмашинному комплексу.)

Дело в том, что ненадежная работа была неотъемлемым свойством всех отечественных ЕС-ЭВМ: на протяжении многих лет я имел возможность в этом убедиться. Типичное проявление этого свойства – зависание машины с частотой несколько раз в час, в зависимости от модели и конкретного экземпляра. Но это я уже узнал в дальнейшем, в свое машинное время, а тогда причины данного явления были мне еще неизвестны. Согласитесь, подобная ситуация, повторяющаяся на каждом дежурстве, у любого вызовет удивление, постепенно переходящее скуку. Дошло до того, что рабочее место ССН даже перестали включать. А затем и дежурство переместилось в небольшое помещение, которое было выделено для всего подразделения защиты информации и использовалось как рабочее сотрудниками подразделения программных средств защиты и подразделения специальных исследований. Там находились несекретная документация, книги, а также белые халаты, без которых вход в машинный зал был воспрещен.

И вот там-то во время одного из своих дежурств я наткнулся на книгу того самого Джермейна, которого советовал читать недружелюбный программист во время моей аудиенции по поводу комплекса М-24. Книга называлась «Программирование на IBM/360». Открыл, стал читать. Текст был понятным – в начале книги описывалась система команд IBM 360, а ЕС-ЭВМ была копией IBM 360. Вот он, момент истины! Оказывается, совет был неплохим, хотя и злобно-ехидным. Далее с интересом прочел про архитектуру, каналы и периферийные устройства. Не знаю, возможно, и ребята ею пользовались – книга эта лежала там все время, – но я на каждом дежурстве читал ее с неослабевающим интересом.

В одно из дежурств, в выходной, я особенно зачитался – обстановка располагала. Неожиданно в полной тишине распахнулась дверь и в комнату вошел руководитель подразделения программных средств защиты Ситников Геннадий Петрович. Оказывается, он иногда (а может и всегда) проверял наличие дежурного в выходные. Увидев, чем я занят, он вдруг предложил мне перейти к нему в сектор. А я тут же и согласился. Вот так просто был совершен поворот в моей жизни.

Дальше последовала небольшая организационная задержка – видимо, мой прежний руководитель возражал, но наконец мой перевод был оформлен. Сбылась «мечта идиота» участвовать в разработке системы.

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

Задание мне поставил в то время старший инженер Ратников Юрий Федорович. Ранее он уже разработал музыкальную программу для дисковой памяти под названием «Тритон», которой постоянно пользовались сотрудники подразделения специальных исследований. Более талантливого инженера и программиста-разработчика, чем он, я впоследствии не встречал. На мой взгляд, был одним из лучших программистов в НИИ, возможно, даже лучшим. Программы он писал быстро и практически сразу работающие, т. е. не требующие отладок. При этом он был очень скромен.

Таким образом, мне нужно было написать программу, которая бы заставила процессор ЭВМ модулировать собственное излучение так, чтобы оно превращалось в музыкальную мелодию. Для этого необходимо было измерять реальную скорость исполнения команд данного конкретного процессора. Затем в соответствии с нотами мелодии строить в оперативной памяти последовательности одной команды для каждой ноты (т. е. для каждой ноты выбираем свою команду). Число команд в последовательности должно соответствовать, по времени исполнения, длительности звучания данной ноты в мелодии. Все это нужно крутить в цикле, чтобы можно было все время слышать мелодию.

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

Ну разве можно такую работу сравнить с тем, чем я занимался раньше? Небо и земля!

На следующий день после постановки задачи состоялось короткое обсуждение будущей программы с Ратниковым. Наш диалог выглядел примерно так: Юрий высказывал свое мнение, а я отвечал «Понятно». В какой-то момент ему, видимо, не понравилось однообразие моих ответов, и он спросил, что именно мне «понятно». Я прокомментировал детали, которые действительно понимал, и вопрос был исчерпан. А ситуация пошла мне на пользу.

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

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

Эти вечерние часы машинного времени до 24:00, в том числе и в выходные, растянулись на много лет, в результате чего я приобрел стойкую привычку работать по вечерам допоздна.

Вот как выглядела технология работы программистов в то время. Код программы мы писали на специальных бланках, которые сдавали в специальный отдел, где их набивали на перфокартах.

Для работы на ЭВМ мы получали диск (или два) с операционной системой в другом специальном отделе. Диск представлял собой набор блинов диаметром сантиметров 50 и весом килограммов 5–7, при этом емкость у него была всего 5 Мб (в 70-е). Хранились диски в цилиндрических футлярах из основания и верхней крышки. Дополнительно получали наш рабочий диск, на котором сохранялись наши программы в трех видах: исходники, объектный код, исполняемый модуль в соответствующих библиотеках. Все диски устанавливались на устройства, внешне похожие на стиральные машины.

Установка. Подходишь к устройству, нажимаешь на нем клавишу для разблокировки крышки устройства, открываешь ее, кладешь диск в футляре рядом. Поворачиваешь несколько раз ручку крышки диска против часовой стрелки и тянешь крышку вверх – основание остается внизу. За ручку крышки устанавливаешь диск на шпиндель устройства, вертишь по часовой стрелке до упора, затем чуть поворачиваешь ручку назад, и… Крышка снимается, а диск остается закрепленным на шпинделе. Закрываешь крышку устройства и нажимаешь одну или две клавиши для запуска – диск начинает с визгом вращаться (визжали на самом деле вентиляторы охлаждения), набирая нужную скорость оборотов. После набора оборотов с таинственным щелчком зажигалась индикация, что устройство готово к работе. Далее можно было загружать операционную систему.

Все это мне страшно нравилось.

Первым компьютером, на котором я написал свою первую «музыкальную» программу, была машина ЕС-ЭВМ 1030 (по-моему, с заводским номером 109). Ее характеристики. Оперативная память – 396 Кб, причем на ферритовых сердечниках (это была расширенная память, стандартная – 256 Кб). Процессор мощностью 100 000 операций в секунду по паспорту (о реальном быстродействии ниже). Периферийные устройства – диски, ленты, парочка устройств чтения перфокарт, пара АЦПУ, что переводится как «алфавитно-цифровое печатающее устройство». Что удивительно, к ней были подсоединены несколько текстовых дисплеев ЕС– 7906, и даже пара графических – ЕС-7064. Все это размещалось в помещении площадью метров 100 в подвале здания бывшей школы. (Как я узнал впоследствии, здание было признано непригодным для школы ввиду его аварийного состояния и потому отошло к нашему НИИ. Получается, что детям там находиться было опасно, а взрослым – в самый раз.)

* * *

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

Была на этом блоке коричневая кнопка для возбуждения прерывания, ей инициировался обмен с ЭВМ (типа современной кнопки «Ввод»), еще какие-то кнопки и индикация в виде маленьких ламп. ЭВМ имела пульт управления – лицевая панель шкафа процессора. На этом пульте была кнопка инициирования начальной загрузки. Также присутствовала различная индикация – содержимое регистров, значение PSW – Program Status Word – слова состояния программы, и другие. Также имелись тумблеры, с помощью которых можно было даже записать PSW и корректировать данные в оперативной памяти.

После нажатия кнопки начальной загрузки начинался диалог на консоли. Мы использовали тогда OS MFT, она предполагала обязательное разделение оперативной памяти на разделы, в которых можно было запускать задания. Диалог одной копии операционной системы состоял из строгой последовательности вопросов (она практически никогда не менялась). В конце диалога мы вводили команды по нашей конфигурации – обычно это были команды монтирования дисков и перевод их в состояние «online». Диалог был на английском языке, так как операционная система была оригинальной системой IBM.

Особым шиком программистов было вводить ответы, не дожидаясь вопросов, так как скорость печати консоли была очень низкой по современным меркам и весь диалог (если ждать вопроса, вводить ответ, опять ждать вопроса, вводить ответ и т. д.) мог занимать 20–30 минут. Поэтому опытные программисты сразу вводили ответы в требуемой последовательности. Такой прием работы как бы подчеркивал опытность и считался своеобразной удалью.

Ответ на вопрос, почему мы сами загружали операционную систему и экономили время, очень простой: зависания тогда были нормой. И если машина не зависала хотя бы час, это уже было счастьем. При зависании имелись две альтернативы – либо восстановить с пульта ЭВМ какое– либо из сохраненных контрольных PSW, либо, если это оказывалось невозможным, перезагрузить систему. По правилам, мы не должны были грузить сами, а должны были вызывать системного программиста. Такой порядок был обусловлен тем, что программисты-разработчики не обязаны были знать загрузку операционной системы (и некоторые ее и не знали).

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

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

Как выглядела эта работа? После загрузки системы мы запускали свои задания, набитые на перфокартах. Для этого стартовала программа из состава операционной системы под названием «reader». После ее запуска я подходил к устройству чтения перфокарт и устанавливал колоду на специальный приемник. После нажатия специальной клавиши устройство с характерным шипением и треском начинало «глотать» колоду. Почему с шипением? Поток воздуха использовался в устройстве для отделения карт друг от друга, а треск возникал от ударов краев перфокарт о детали приемного механизма. Если колода считывалась без ошибок, устройство затихало.

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

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

Это было обычное задание программиста из трех шагов на языке JCL – Job Control Language. Если программа не имела ошибок и работала корректно, то вы либо работали с ней в диалоге через консоль, либо она выполнялась и печатала результаты работы на АЦПУ. В случае возникновения ошибок программа завершалась аварийно и на печать выводился дамп всего раздела оперативной памяти, где выполнялась программа. Этот дамп был основным и единственным средством отладки программ.

Расскажу, как мы с ним работали.

Дамп – это содержимое всех регистров и памяти раздела в шестнадцатеричном виде на момент прерывания работы программы из-за ошибки. Также в дампе указывался адрЕС-последней команды, на которой произошло прерывание. Имея эти данные и листинг транслятора можно было анализировать ситуацию и так или иначе всегда обнаруживалась причина ошибки. Обычно это бывали элементарная описка, ошибка в алгоритме программы, ошибка в условном переходе, зацикливание. В последнем случае бывало или аварийное завершение по переполнению или приходилось аварийно снимать задание с тем же дампом. Вот так – никаких дисплеев, дебагеров, а главное, никакого нынешнего комфорта. Шум в машинном зале от множества вентиляторов в шкафах оборудования стоял невообразимый, не говоря уже о треске АЦПУ и шипении считывателей перфокарт.

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

Кстати, то же самое привилегированное состояние по тем же причинам требовалось и для проигрывания мелодии. Нужно сказать, что по кнопке начальной загрузки можно было загрузить не операционную систему, а исполняемый код своей программы, например, на тех же перфокартах. Если мне не изменяет память, рядом с кнопкой загрузки на пульте ЭВМ помещался указатель адреса устройства загрузки. По-моему, это были три колесика с гранями. На гранях – шестнадцатеричные цифры от 0 до F. Прокручивая эти колеса можно было задать адрес загрузки с любого устройства, например с устройства чтения перфокарт (они обычно имели адреса 00A – 00C). Однако в этом случае работать на ЭВМ никто больше не смог бы.