Опыт конвертации Фортрана

Опыт конвертации Фортрана

В году 1979 коллеги по лаборатории отдела 200 ЦНИИКА попросили меня сделать две вещи:

1. Написать на ассемблере ЕС ЭВМ (советский аналог IBM System/360) подпрограмму, которая вызывается из программы на Фортране этой машины и меняет в двухбайтовой целочисленной переменной (integer *2) байты местами. Зачем им это потребовалось, не знаю – они разрабатывали какой-то интерпретатор для АСУ ТП, причём писали его на Фортране 4. Об этом чуть дальше. Стыковка с ассемблерным модулем, к счастью, была хорошо описана в документации на Фортран ЕС ЭВМ, а главное всё работало. В ту пору никаких доступных языков типа Си на этих машинах не было, и программы свои я писал большей частью на Ассемблере 360, который был прекрасно описан в очень популярном тогда учебнике Д. Стебли «Логическое программирование в системе 360» (–М.: Мир, 1974 г.).

Бытует мнение, что программировать на ассемблерах очень трудоёмко, однако уже в те времена в них были макросредства, или, иначе говоря, встроенный макроязык, позволявший объединять блок ассемблерных команд под одним именем, т. е. создавать макрокоманды, писать эти макрокоманды вместо команд ассемблера и передавать им всевозможные параметры. Существовали в ассемблерах и средства так называемой условной трансляции (они обычно есть и в трансляторах с ЯВУ), с помощью которых макрокоманду можно было сконфигурировать под некоторую задачу, например генерацию операционной системы. Использование макросредств позволяло повысить уровень ассемблера до полноценного ЯВУ. Поэтому вначале обычно шла разработка и отладка макросов, из них создавалась макробиблиотека, а потом на этих макросах (если не было готовых библиотек) писалась нужная программа. Получался такой проблемно-ориентированный язык высокого уровня. Таким образом, в частности, в конце 1970-х была написана система резервирования авиабилетов «Сирена-2».

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

2. Другая просьба коллег вначале выглядела совсем невинно: вывести перфоленту с исходным текстом на Фортране 4 с большой машины (М-4030 или ЕС-1035), чтобы перенести её на целевую машину М-7000 (позже её переименовали в СМ-2). Вся прелесть состояла в том, что эти машины работали с разной кодировкой символов: на больших машинах использовался код EBCDIC (расширенный двоично-десятичный код обмена информацией; произносится «Эб-си-дик»), а на М-7000 применялся расширенный код ASCII. Поэтому текст программы перед выводом на перфоленту нужно было перекодировать. К счастью обе кодовые таблицы 8-разрядные. Получив желаемые перфоленточки, коллеги обнаружили, что на M-7000 имеется только компилятор с Фортран-2, языка предыдущего поколения, который сильно отличается от Фортрана-4. Вот тут собака зарыта в проблемах совместимости снизу вверх и сверху вниз.

Совместимость снизу вверх означает, что программа, разработанная на ранних версиях языка, должна работать и на его более поздних версиях, когда в язык уже добавлены новые функции и новые конструкции. Разработчики ЯВУ стараются максимально сохранить эту совместимость, чтобы не пропал накопленный багаж разработок, выполненных на ранних версиях – то, что называют унаследованным ПО. Когда это не соблюдается, то от пользователей идёт очень жёсткая критика. Наиболее известный недавний прецедент – переход с Python 2 на Python 3. Разработчику языка Python Гвидо ван Россуму пришлось выслушать немало упрёков по этому поводу.

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

Для начала я составил довольно длинную таблицу отличий Фортрана 2 от Фортрана 4. Очень помогла книга Э.В. Трахтенгерца «Язык программирования Фортран 2». Многие отличия, но, к сожалению, не все, можно было убрать программно. Я начал расширять программку вывода на перфоленту, убирая в первую очередь различия, требовавшие много механического ручного труда – там было какое-то несовпадения типа кавычек и т. п. Нужно сказать, что анализ сильно упрощала структура фортрановской программы с чётко обозначенными полями: первые пять символов числовая метка, 6-й символ – признак комментария, потом следует сам оператор и в конце номер перфокарты, который позволяет собрать колоду перфокарт в правильном порядке, если она рассыпалась. Такой случай у нас на ВЦ был с довольно большой колодой из примерно 600 перфокарт и наш техник потратила несколько часов, чтобы разложить их в правильном порядке. Сейчас перфоленты и перфокарты многие программисты в глаза не видели, а для нас это были такие же обыденные привычные вещи, как нынешние флэшки. В итоге программа, которую я назвал «Конвертер Фортрана 4 в Фортран 2», за пару месяцев разрослась до 10 тыс. строк на ассемблере. Больше всего пришлось повозиться с именованными областями COMMON – через них в Фортране часто передают параметры другим модулям. До какого-то коммерческого продукта довести этот конвертер времени уже не было – софт на целевую машину перевели и запустили, лаборатория получила за него три медали ВДНХ, начался другой проект, да и программы в те времена как правило ничего не стоили.

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

Москва, ноябрь 2023 г.

Об авторе: Директор Виртуального Компьютерного Музея
Помещена в музей с разрешения автора 5 декабря 2023