Про баннер podvignaroda.ru и моего отца

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

             После смерти отца в 1990 году я, как старший наследник, бережно храню его боевые ордена и медали. На сайте я нашел наградные дела на два ордена, но у моего отца их – три. Про первый из них есть только упоминание в деле 1945 года:

            «Инженер-капитан ТЕРЕХОВ за отличную работу в первые дни (прим. выделено мною) Отечественной войны на ЛФ и ВФ в августе 1943 г. награжден орденом «КРАСНАЯ ЗВЕЗДА».

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

             Мой отец, Терехов Николай Васильевич, 1914-го года рождения (г. Петроград), вырос в бедности. Его отец Терехов Василий Антонович был мастером Путиловского завода, умер от тифа в 1918 году. Мать, Агафья Андреевна, воспитывала отца и его сестру (1917-го года рождения) одна, работала на Красном Треугольнике, жили они в доме на углу Обводного канала и улицы Шкапина (сейчас этот дом снесен) до середины 60-ых годов. Я там бывал и всегда ужасался –28 комнат в одном коридоре.

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

             Мой отец прошел всю Великую отечественную войну, получил три ордена, много медалей, войну закончил в Вене. Он очень не любил рассказывать о войне. Говорил, что война – это грязь, кровь и тяжелая будничная работа. Только изредка мне удавалось разговорить его на какую-нибудь военную тему. Одним из таких редких примеров был рассказ о Вене. По его словам, Вену брали только с помощью пехоты и маленьких пушек. Говорят, был приказ Сталина, в котором говорилось, что мы – не варвары, поэтому мы не можем разрушить многочисленные венские дворцы. Я думаю, что мой отец и не видал этого приказа, но в армии говорили, что Вену бомбить и обстреливать из тяжелых пушек нельзя. В результате, при взятии Вены мы потеряли 35000 человек, а ведь это уже был май 45-го года. Разумеется, я не ручаюсь за точность этих цифр – я не историк, а просто рассказываю всё со слов отца. Так вот, когда Вену взяли, мой отец долго гулял по ней, он знал немецкий язык, поэтому мог общаться с горожанами. На него неизгладимое впечатление произвел дворец, в котором целые залы были только из золота и зеркал. Не буду скрывать, что он несколько раз говорил, что 35000 жизней – слишком тяжелая плата за сохраненные зеркальные залы.

              В начале 2000-ых годов мы с женой провели две недели в Вене по приглашению нашего одногруппника – венгра Сёке Петера. Мне было интересно разыскать тот самый дворец. Кажется, это Бельведер. Там действительно два здания на холме и в низине, причем в нижнем дворце действительно есть огромные залы, все стены которых покрыты зеркалами в золоте. Чтобы уточнить, какие-то вопросы, я стал спрашивать экскурсовода, сказав, что мой отец освобождал Вену. В ответ услышал: «Так Ваш отец был оккупантом?». Черт их разберет, этих австрияков. С одной стороны, они говорят, что были первой жертвой Гитлера (аншлюс 1937 года), а, с другой, – в музеях Вены я видел фотографии, где толпа в полмиллиона человек восторженно кричит «Хайль Гитлер», приветствуя приезд фюрера. Мой отец не был оккупантом.

             После окончания Великой Отечественной Войны прямо из Вены дивизию отца переправили на Дальний Восток (он рассказывал, что сделали огромный крюк через Румынию, так как по Западной Украине ехать было просто опасно). Мой отец принял участие и в третьей своей войне, потом два года служил в Харбине, но это уже совсем другая история.

            Когда я был в седьмом классе (в 1963 году), перед празднованием Дня Победы наша классная руководительница Нелли Дмитриевна Сога попросила всех учеников, чьи отцы воевали, записать их короткие воспоминания для классной стенгазеты. Естественно, я тоже попросил своего отца. Он долго отнекивался, говорил, что он не писатель и вспоминать особенно нечего. Но после моего нажима написал от руки страницу тушью (не чернилами!), где говорил, что предыдущая война была войной моторов, а будущая война будет войной электроники и умных машин, поэтому, чтобы защищать Родину, нам надо хорошо учиться. Невозможно сказать, как я обиделся. Другие отцы стреляли, ходили в разведку, а мой отец говорит, что надо учиться. Кое-что о собственном отце я узнал только через 2 года.

             Девятого мая 1965 года в первый раз было поистине всенародное празднование Дня Победы. Кажется, только в этом году праздник сделали нерабочим днем. Ко многим ленинградцам приехали их однополчане из других городов, столы были накрыты прямо во дворах, везде было слышно хоровое пение, игра на гармошке,все люди несли водку и закуску, не было своих и чужих. К нам приехало более 80 человек из отцовской дивизии, ночевали у соседей, у нас тоже ночевало человек 10-15. Огромный стол был накрыт прямо у нас под окнами. Я заканчивал 9-ый класс математической школы, то есть был уже большим мальчиком, но мне было жутко интересно, поэтому я вертелся среди однополчан, пытался говорить с ними – тот был лучшим мотористом, тот был лучшим штурманом. И тут мне сказали, что отец был лучшим радистом. Более того, что он их всех спас. Я не верил своим ушам. Вот что мне было рассказано одним дядькой (к сожалению, не помню, как его зовут, но помню, что он был из Мукачево (под Ужгородом), куда мы этим же летом поехали отдыхать):

             В их дивизии на вооружении стояли тяжелые ночные бомбардировщики ТБ-3. Во многих книгах и фильмах о первых днях войны показано, как легко немецкие истребители сбивали эти медленные большие машины. Но у ТБ-3 и применение по уставу было совершенно другим, они поднимали бомб больше всех других самолетов(кажется, не только советских), должны были бомбить только ночью, поэтому конструктор А.Н.Туполев выбрал большую грузоподъемность в ущерб скорости. Правильность этого выбора была доказана на опыте отцовской дивизии. Аккуратно все самолеты вылетали каждую ночь, бомбили разные цели, причем потерь практически не было. Аэродром и склады были в глубине огромного лесного массива, на всех дорогах были устроены завалы из больших деревьев. В начале сентября 1941 года дивизия оказалась в глубоком тылу у немцев, фронт был уже под Ленинградом, но дивизия продолжала исправно воевать. Запасов бомб, горюче-смазочных материалов, еды и всего остального хватало, немцы никак не могли разыскать запрятанный в лесах аэродром, но связь с командованием уже давно была потеряна. Офицеры пытались сказать командиру, что надо бы отступить, что мы уже далеко в тылу у немцев, но командир наотрез отказывался самостоятельно отдать приказ об отступлении. У всех на слуху был приказ Сталина, по которому расстреляли Героя Советского Союза Павлова за то, что он отдал приказ об отступлении. Тогда офицеры стали просить моего отца организовать связь с «Большой землей», чтобы получить приказ оттуда. Мой отец целую ночь рассчитывал рамочную антенну (вот где пригодилась зашитая в китель книжка), потом всем миром устанавливали и направляли антенну, сделанную из больших сосен. Связь была установлена, причем качество было как по телефону. Командир армии, в которую входила дивизия, очень обрадовался –он был уверен, что дивизия уже не существует, и отдал приказ о перебазировании в Ленинград (обратите внимание – не об отступлении, а о перебазировании). Весь состав дивизии погрузили в самолеты, оставшееся хозяйство взорвали и полетели.Именно за этот установленный сеанс связи отец получил свой первый орден Красной Звезды.

             Таким образом, мой отец попал в блокадный Ленинград, может быть, именно поэтому выжили моя бабушка и тетя. Из смешных воспоминаний, а были и такие в то жуткое время, он часто рассказывал, как ездил на 36 трамвае с фронта к матери на Обводный канал. А ещё в нашей семье часто вспоминают, что мой отец говорил, что я должен учиться в университете, когда я был ещё в первом классе. Тогда же мне было сказано, что я, как и он,должен получить красный диплом. Все 10 лет моей школы отец, как мантру, повторял: «Учи математику и английский язык. Всё остальное ты можешь выучить и потом, а математику и английский надо учить с детства». Я получил красный диплом мат-меха, но когда я заглянул после его смерти в его диплом, он действительно красный (с отличием), но там есть даже две тройки. В 1939 году требования к красному диплому были слабее. У меня троек нет

            Когда я пристал к отцу с просьбой подтвердить или опровергнуть эту историю о перебазировании дивизии в блокадный Ленинград, он сказал: «Что тут особенного, это и есть моя работа. Было не так страшно лететь, как было ужасно холодно». И всё. Эта история произвела на меня большое впечатление, я сразу вспомнил ту страницу, написанную тушью для школьной стенгазеты, и теперь она мне не показалась такой абстрактной и нравоучительной.

Мои первые пять лет на мат-мехе

До мат. меха

            На мат-мех я попал, в общем-то, случайно. Мой отец был военным электронщиком, поэтому я еще с шестого класса увлекся радиолюбительством. Особенно мне нравилось собирать нетривиальные радиотехнические устройства. Я думал поступать в Институт связи им.Бонч-Бруевича, который закончил мой отец, или в ЛЭТИ. Но за два месяца до окончания школы мой лучший друг и одноклассник Миша Стерлин мельком упомянул, что на мат-мехе, куда он собирается поступать, нет черчения, химии и начертательной геометрии, которые я ненавидел. Учились мы в 157-ой школе (около Смольного), кажется, это была первая математическая школа в Ленинграде, которая в сталинские времена была школой для детей ОБКОМовцев, а в хрущевские времена, чтобы не отдавать на разграбление старую гимназию, сделали из нее экспериментальную школу Академии Педагогических наук. Там было две ЭВМ Урал-1 и две «тетеньки» по 25 лет, которые умели их ремонтировать и программировать на них. Я решил, что это прямое продолжение радиолюбительства, поэтому мое первое знакомство с ЭВМ началось с изучения электроники. Я действительно научился их ремонтировать, а ломались они очень часто. По окончании школы я получил 1-ый разряд программиста (точно такой же, как у токарей и слесарей). Те, кто заканчивал одиннадцатый класс нашей школы получали 3-ий разряд, а я был первым выпуском десятого класса, поэтому до 3-го разряда не дотянул. 1966 год –самый кошмарный год для абитуриентов. Школу закончили одновременно выпускники десятых и одиннадцатых классов, поэтому конкурс в вузы просто удвоился. Школа была математическая, поэтому какая-то математическая подготовка у меня была, но ни в каких олимпиадах я не участвовал и вообще не связывал свою будущую жизнь с математикой. Но желание обойтись без химии и прочих глупостей пересилило. Я подал документы на мат-мех.

Поступление на мат-мех

            В те годы самым страшным экзаменом была письменная математика. Задачи давали действительно очень трудные, обычно отбор завершался после первого же экзамена. Мы с Мишей Стерлиным получили по «4». Я радовался, а он огорчился. В отличие от меня, он с девятого класса изучал математический анализ, переписывался с известным ученым Г.Е. Шиловым, в учебнике которого по дополнительным главам матанализа он нашел несколько ошибок. Потом на устной математике я получил тоже «4», меня малость срезал А.В.Яковлев задачей по комбинаторике, которой не было в школьной программе. Через много лет, когда я уже стал профессором мат-меха, я напомнил ему об этом грустном эпизоде моей биографии. Оказалось, он помнил этот случай, сказал, что я был очень нахальным, что ему не понравилось. Потом была четверка по физике (я до сих пор абсолютно уверен, что меня незаслуженно обидели) и три балла по сочинению (я два раза написал «привЕлегия»в сочинении по образу врагов в романах Шолохова). В результате, Миша попал на дневное отделение мат-меха, но только на механику, что его очень расстраивало, а я вообще не попал на дневное отделение. Правда, меня без экзаменов зачислили на вечернее отделение.

Первый год мат-меха

          Тогда были довольно жесткие правила: если ты учишься на вечернем, то обязан работать. Я стал искать работу по специальности, но программисты нужны были только в военных организациях, а мне только что исполнилось 17 лет, поэтому даже разговоров о второй форме допуска не было. Особенно мне запомнилась двухчасовая беседа в 233-ем ящике (Дом Советов на Московском) с начальником ВЦ Кацевым Борисом Ароновичем. Он мне устроил настоящий экзамен, я все успешно выдержал, а потом он с сожалением сказал, что все равно ничего не выйдет из-за моей молодости. Через много лет он стал работать преподавателем на кафедре матобеспечения ЭВМ на мат-мехе. Естественно, я ему напомнил о том случае, он сказал, что ему было просто интересно, чему учат в матшколах. Я искал работу целый месяц. Моя любимая классная руководительница Людмила Викторовна звонила мне чуть ли не каждый день, оказалось, что я единственный из 165 выпускников школы не поступил в вуз, а теперь я еще и тунеядец, поскольку не работаю, чем порчу их замечательную статистику.

             Как-то в метро моя мать случайно услышала разговор, что на Фонтанке открылся новый институт «Ленэлектронмаш»и там набирают программистов. Точного адреса я не знал, но тут же рванул туда. Это было 1 октября 1966 года. Нашел довольно быстро – Фонтанка, 6 – в этом здании было когда-то училище правоведения, в котором учился Чайковский. Именно про них сочинили песенку «чижик-пыжик, где ты был?». Встретил меня директор Вычислительного центра Зубарев Борис Иванович, очень доброжелательно побеседовал со мной, а когда увидел разряд программиста (напоминаю, самый низкий), так просто обрадовался и тут же взял меня на работу. В ВЦ было 2 машины Минск-22, человек 15 выпускников ЛЭТИ инженеров и ни одного программиста. Около месяца я был в подчинении у девушки-руководителя группы операторов, которые набивали перфоленты, а потом сам стал руководителем группы, в которой у меня было 4 подчиненных – все старше меня на 10 лет. Минск-22 я освоил довольно быстро, но остро чувствовал нехватку общения с коллегами. Мои подчиненные так и не научились реально программировать. 10 октября того же года к нам на работу пришел Гена Дейкало (ныне начальник всех вычислительных классов мат-меха), который отслужил около 3,5 лет в Космическом ВЦ между Евпаторией и Симферополем и был настолько важным специалистом, что его полгода не отпускали из армии. Его взяли техником на ремонт перфорирующих устройств, но оказалось, что он лучше всех знает и электронику, и программирование Минска-22. Жить стало веселее.

             На занятия на вечерний мат-мех я ходил аккуратно, лекции нам читали  Гаральд  Исидорович Натансон, Зенон Иванович Боревич, а практику по алгебре вел тот самый Толя Яковлев из-за которого я не поступил на дневное. Одно из забавных воспоминаний этого времени –кроме меня из всей моей группы не работал никто, все имели фальшивые справки. Один мальчик умудрился получить фальшивую справку даже из Народного суда. Над тем фактом, что я, правда,работаю, потешались все. Многие ходили на дневные занятия как обычные студенты. Потом, при переходе с вечернего на дневное, им не пришлось ничего пересдавать.

           Работа в «Ленэлектронмаше»мне очень нравилась. Мы делали АСУ для Краснодарского завода измерительных приборов, которая в числе 5 реально работающих АСУ была упомянута на каком-то Съезде КПСС. Я отвечал за подсистему комплектующих изделий. Руководителем всех работ был Виталий Линденбаум, который работал не в ВЦ, а в большом «Ленэлектронмаше»(Красная, 7). Помню, как я донимал его вопросами, почему мы не занимаемся оптимизациями, а только «из двух файлов склеить третий». Он доходчиво объяснил, что мы – «ассенизаторы»: на заводе 20-30 типов бланков заказов, 30-40 бланков отчетов и т.д., наша задача –навести хотя бы минимальный порядок. Вы будете смеяться, но в наше время постановка задачи нисколько не изменилась.

           Параллельно мы с Геной Дейкало занимались рационализаторством (6 документально оформленных «рацух»). Оказалось, что в Минске-22 есть огромный избыток аппаратуры, который отлично можно приспособить для других целей. Кончилось тем, что мы сделали Автооператор, который запускал очередное задание после завершения (успешного или аварийного) предыдущего. Теперь это называется пакетной обработкой, но такой термин в русском языке появился лет через пять после нас. Мы попытались получить авторское свидетельство на Автооператор, но получили издевательский ответ, что всё это уже известно в Америке под именем OS/360. Откуда нам было про это знать за «железным занавесом»? Но все-таки обратите внимание, что в те времена отставание было 3-5 лет (IBM360 была объявлена в 1964 году), а не десятки лет, как сейчас. Через три года инженеры мат-меха решили сделать то же самое на М-20. Они слышали, что кто-то в «Ленэлектронмаше»подобную вещь сделал, но не знали кто. Меня разыскал Александр Николаевич Балуев и очень удивился, узнав, что я студент мат-меха.

            Первый курс вечернего отделения я окончил на одни пятерки и спокойно уехал в отпуск на юга. Когда вернулся, с удивлением обнаружил, что меня нет в списках студентов вечернего отделения. Зам.декана по вечернему отделению Светлана Михайловна Владимирова в ответ на мои возмущенные вопли спокойно сказала, что мне лучше быть студентом дневного, поэтому она перевела меня даже без моего заявления. Я немного поупирался, поскольку работа мне очень нравилась, но все решилось благополучно, когда директор ВЦ «Ленэлектронмаша»оставил меня под свою ответственность на полной ставке руководителя группы, несмотря на то, что я студент дневного отделения.Те ребята, который учились со мной в одной группе на вечернем отделении, закончили мат-мех через 3-4 года после меня, у некоторых из них я был научным руководителем дипломного проекта или рецензентом. С.М. Владимирову я больше не видел, но всегда хотел ей сказать спасибо за то, что она за меня все решила.

Дневной мат-мех

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

           Миша Стерлин тоже завершил первый курс без единой четверки и его перевели на отделение математики, так что в 22-ой группе мы снова сидели с ним за одной партой, как в школе.

            На дневном отделении за первый курс начитали гораздо больше материала, чем на вечернем, поэтому предстояло досдать несколько дисциплин. Г.И. Натансон экзамены по анализу мне просто перезачел, к моему счастью, когда я учился на вечернем, матлогику читал профессор Н.А.Шанин по субботам, поэтому я не пропустил ни одной лекции и спокойно получил зачет вместе со всеми. Салгеброй было хуже, пришлось второпях сдавать довольно большую разницу и я получил первую для себя на мат-мехе «4». Еще одну четверку я получил по аналитической геометрии. В те годы стипендию давали только тем студентам, у кого доход в семье был меньше ста рублей «на брата». В нашей семье это было не так, поэтому я остался без стипендии(35 р.). Чуть позже я узнал, что отличникам дают стипендию (43 р.) в любом случае, поэтому больше я не получал четверок. На четвертом курсе я женился на своей одногруппнице Гале Максютовой, которая презрительно относилась ко всяким гуманитарным марксистско-ленинским наукам, никогда их не учила и спокойно получала четверки. При мне она ни одной четверки не получила(и получала повышенную стипендию, которая в это время достигла 62,5 р.), я ей доходчиво объяснил, что разница в 15 рублей –это стоимость комнаты, которую мы снимали. Квартиру тогда можно было снять за 25-30 рублей (т.е. за две разницы).

             Ни в какие стройотряды я не ездил, лето было для меня самая трудовая пора, поскольку кроме «Ленэлектронмаша»я стал работать еще во всяких других местах. Не то, чтобы я был очень жадным, просто год вечернего мат-меха показал мне разницу между студентом, изучающим программирование, и реальным программистом. А я был таким реальным программистом. Тогда каждый студент получил карту времени –перфокарту, на которой отмечалось время, затраченное на пропуск его заданий на М-20. Все мои задачи проходили с первого раза, а карту времени я использовал для халтур. Один студент нашей группы стал практиковать выполнение студенческих программистских заданий за 3 рубля с человека. Меня это страшно возмутило, чтобы сбить ему эту систему, я объявил, что всем студентам делаю их программы совершенно бесплатно, но забирал их карты времени. В результате,я получил возможность просчитывать на машинах мат-меха десятки задач, я писал на заказ кандидатские диссертации по техническим наукам (например, моделирование поворота подводной лодки), по химии (очистка редкоземельных металлов через дорогущие смолы) и даже по филологии (по тому, что буква «Ф» в поэме Пушкина «Полтава» встретилась только три раза, какой-то филолог доказал, что буква «Ф» появилась в русском языке позже других).

             Первая моя публикация –«Код Шеннона-Фено по методу Хаффмана» была в маленьком мат-меховском сборнике, а первая публикация во всесоюзном журнале появилась как раз в результате халтуры на заводе им.Свердлова. Там делали шлифовальные станки с магнитным столом, чтобы деталь не двигалась и не крутилась, нужно было рассчитать интегралы сил и моментов, а в этих интегралах была дробь, в знаменателе которой иногда встречался 0. Мне удалось найти чисто программистское решение этой проблемы, грубо говоря, я сначала рассчитывал кривую, которая приводила к нулю в знаменателе, а потом считал интегралы слева и справа от этой кривой. Расчеты идеально совпали с практикой, здесь я впервые столкнулся с явлением приписывания соавторов. Сначала мы выступили на какой-то маленькой городской конференции с Гальпериным Борисом Яковлевичем, который и заказал мне эту работу, потом на более крупной конференции к нам приписался начальник его отдела, а во всесоюзном журнале «Вопросы машиностроения» к нам приписался еще какой-то кандидат технических наук, которого я и в глаза не видел.

            Когда я закончил школу, у меня был рост 163 см. Я обожал баскетбол, но у меня не было никаких шансов. За первый курс я вырос на 20 см, а за первый год после женитьбы я с 46 размера я перешел на 56. На встречах класса меня никто не узнает. Когда я перешел на дневное отделение, то сразу же рванулна баскетбольную секцию, но ее тренер Виктор Иванович Рудакас меня не взял (сказал, что я слишком хилый). Я сумел пробиться в команду завода Большевик, стал известным на весь город костоломом (если я пробивал штрафные меньше 20 раз за игру, тренер на меня орал, что я халтурю). Мы играли в той же лиге, что и Университет, Рудакас на меня очень обижался, а за что? Позже я стал играть под его руководством на Первенстве города среди сотрудников вузов. Как-то раз мы даже стали чемпионами.

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

Кафедра матобеспечения ЭВМ

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

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

             Я поступил следующим образом. Во-первых, договорился с Марком Константиновичем Гавуриным (вообще-то, его настоящее имя-отчество было Мордух Калманович, но все звали его именно так, как я сказал), чтобы он на каждой своей лекции давал мне 15 минут для произнесения речи.Во-вторых, я вообще не стал упоминать о кафедре и моем поручении. В первый раз я вышел и сказал: «Вот, неделю назад я получил 200 рублей за работу по моделированию поворота атомной подводной лодки». Подробно рассказал про задачу, что я там программировал,как я доказывал, что мои результаты адекватны и так далее. Гавурин хорошо знал, зачем я это делаю, но даже вида не подал,что я говорю что-то не то. Через неделю я сказал, что я получил еще 150 рублей, решив задачу вариационного исчисления в интересах очистки редкоземельных металлов. На третьей неделе я тоже начал о чем-то рассказывать, но тут народ взвился и все стали требовать объяснения, к чему я клоню. Тут я всё и рассказал. Мне удалось уговорить 15 человек, семь из которых впоследствии получили красный диплом. Еще двух девушек кто-то уговорил и без меня. Поскольку все новые студенты кафедры имели только начальные знания о программировании, полученные на первом-втором курсе мат-меха, я организовал кружок по технике трансляции, на котором рассказывал, чем мы занимаемся в рамках проекта реализации Алгола 68. Никакой конкретики, договора или еще чего-либо в этом роде тогда еще не было, но мой научный руководитель Григорий Самуилович Цейтин уже поставил перед нами эту задачу.

              Кстати, уже будучи студентом пятого курса, я поехал подписывать первый договор по этой теме в Москву в НИЦЭВТ (старшие товарищи по разным причинам уклонились от этой работы). Так получилось, что я поехал на вокзал сразу после игры, где мне поставили огромный кровоточащий синяк под глазом. Я очень беспокоился, что этот печальный факт создаст обо мне негативное впечатление и договор не подпишут. Но, на мое счастье, зам.генерального директора НИЦЭВТа Хахалин оказался мастером спорта по боксу и сказал, что синяк – это нормальное мужское дело. Именно в этот памятный визит я впервые познакомился с будущим академиком Андреем Петровичем Ершовым, который сам приехал подписывать контракт на оптимизирующий транслятор с Алгола 68, а мы делали отладочный транслятор.

              На новой кафедре я стал нештатным преподавателем, практически со всеми беседовал долгими часами. Как-то программировать умели все, но что такое системное программирование, практически никто не знал. Я рассказывал про свои работы, помогал сформулировать темы дипломных работ, а потом консультировал в ходе работы над ними.По крайней мере, 6 дипломных работ я знал не хуже их авторов. Особенно много пришлось заниматься с двумя венграми –Сёке Петером и Андрашем Шоймоши.Формально, у Петера руководителем был Г.С.Цейтин, а у Андраша –Б.К.Мартыненко, но им было как-то легче общаться со мной, чем со своими научными руководителями.Оба потом защитили кандидатские диссертации, Андраш сейчас профессор Технического Университета Берлина, а Петер живет и работает в Вене. Из нашего первого выпуска Света Селеджи теперь зам.декана мат-меха, Наталия Вояковская – старший преподаватель моей кафедры, единственная среди наших орденоносец, отмеченная этой наградой за то, что тренировала первых российских чемпионов мира по программированию среди студентов, моя жена Галя Терехова уже на пенсии, но всю жизнь успешно проработала на мат-мехе программистом. Женя Русаков по-прежнему работает на мат-мехе, мы с ним учились на первом курсе в одной группе на вечернем отделении. Толя Нырков сейчас профессор в Университете водного транспорта, я был у него оппонентом по докторской диссертации.

Военные сборы

             После 4-го курса мы поехали на военные сборы в Пери (сразу за Кавголово). Я начал с нескольких нарядов вне очереди, так как не захотел подстригаться, а прическа у меня была, как у Анжелы Дэвис (сейчас я практически лысый). Но потом жизнь наладилась, было даже интересно. Запомнилось, как какой-то майор объяснял нам, математикам, азы теории вероятности: «Как N изделиями лучше обслужить M целей». Имелось в виду, как истратить минимальное количество ракет на поражение заданного количества целей. Слово «обслужить» после этого много лет было у нас любимым. Что было хреново –так это еда. Зеленые соленые помидоры и перловая каша с толстым слоем зеленого жира –это что-то! Меня и моих друзей спасала моя жена, которая приезжала каждое воскресенье с огромной сумкой еды и нас кормила. Мы считались курсантами, а не солдатами, поэтому официальных жен допускали на территорию части в выходные. Как я уже говорил, меня сильно «гнобил» полковник Аникеев, это продолжалось и в части, в частности, он запрещал мне встречи с женой, мотивируя моими внеочередными нарядами. Но и тут мне удалось найти выход – старшиной нашей роты был товарищ из Белоруссии (кажется, его фамилия была Янукович), который говорил «вешэство». Как только я упомянул, что моя жена из Гродно(естественно, я сказал «с Хгродна»), он тут же проникся ко мне добрыми чувствами и по воскресеньям отпускал меня «под забор» –территория части была огромной, можно было, не выходя из части, хорошо спрятаться.

             На четвертом курсе я был секретчиком на военной кафедре. В мою обязанность входило получать чемодан с секретными книгами и под пропуска выдавать их студентам. Естественно, я не следил за этим так уж тщательно. Как-то раз один из студентов нашей группы забыл дома пропуск, прошел на военную кафедру по чужому пропуску, соответственно, книгу из секретного чемодана взял, не положив туда пропуск. На нашу беду,с проверкой пришел подполковник Чечин – главный секретчик военной кафедры (на первом занятии кафедры на втором курсе он учил нас секретности, используя очень забавные и очень неприличные примеры), потребовал сдать все книги, слава богу, все книги оказались на месте, но поскольку нарушение было замечено, всей нашей группе запретили выдачу книг. Поэтому на госэкзамен по военке мы шли с половиной не выученных билетов. Перед началом госэкзамена Аникеев публично заявил, что он сдохнет, но не даст мне получить красный диплом, и спрашивать меня он будет лично. Но прямо во время экзамена его вызвали к телефону по звонку из Генштаба, потом оказалось, что он попал в число военных советников в Египет. А пока он говорил по телефону, я успел проскочить и получить свои пять баллов. Пусть после этого кто-нибудь усомнится, что я не самый главный «прушник».

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

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

Общественники

            Моя жена отвечала за академ.работу курса, иногда рассказывала забавные истории, как она ходила домой к преподавателям просить за двоечников. Вместо того, чтобы за кого-то просить, я с этими двоечниками занимался. Тогда было принято, что группа в 3-5 человек перед экзаменом собирается у кого-нибудь на квартире или в общаге, так как вечно не хватало конспектов, книг и т.д., да, и готовиться коллективно легче –можно обсудить сложный вопрос, кто-то что-то вспомнит. Так вот, моя жена готовилась к экзаменам в компании с отличниками, а я со своими друзьями-спортсменами, которые почему-то были всегда среди неуспевающих. Одному из тех, с кем я занимался, – чемпиону Ленинграда по боксу в тяжелом весе –моя мама-врач выписывала справки о его болезни. Он таки кончил мат-мех, но через 5 лет. Зато нам ничего не стоило в два часа ночи выйти во двор поиграть в хоккей, когда заниматься было уже невмоготу.

           Организаторы подготовки данного сборника воспоминаний почему-то задали несколько вопросов про наше отношение к комсомолу в студенческие годы. Мне сказать почти что нечего. К комсомольским лидерам я относился с подозрением, считал их карьеристами. Перед самым дипломом у нас в группе один студент был осужден за хулиганство, причем история была весьма некрасивой. Как водится, в группе состоялось комсомольское собрание, на котором мы должны были подписать характеристику этому парню. Комсомольские вожаки организовали бешеное давление на студентов нашей группы, что, мол, зачем портить парню жизнь. А на самом деле, я уверен, боялись получить пятно на комсомольскую организацию мат-меха. Им это даже удалось, против положительной характеристики проголосовало всего два человека – моя жена и я. Хулигану это не помогло, ему дали 10 месяцев настоящей тюрьмы. Я сам на суде не был, но мне рассказывали, что женщина-судья обругала студента нашей группы, зачитывающего положительную характеристику. Еще один случай: в военных лагерях мы поймали с поличным парня, который воровал книги и другое имущество у своих же студентов. Он оказался членом партии. Из партии его не исключили, «партия –это не проходной двор, надо воспитывать». После таких случаев (я рассказал только о двух из них) я твердо решил держаться подальше от общественной работы.

Заключение

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

                                         Зав.кафедрой системного программирования СПбГУ

                                           Генеральный директор ЗАО «Ланит-Терком»

                                                  Генеральный директор ГУП «Терком»

                                              Доктор физ-мат наук, профессор А.Н.Терехов

История нашего коллектива глазами А.Н.Терехова

1. Трансляторы

              Я закончил мат-мех ЛГУ с отличием в 1971 году (первым защитил диплом в первом выпуске кафедры матобеспечения ЭВМ). Моим научным руководителем был доктор физ.-мат. наук Григорий Самуилович Цейтин – сильный и разносторонний ученый. В то время он руководил лабораторией матлингвистики НИИММ ЛГУ, достиг выдающихся успехов в матлогике и теории сложности вычислений, но основным его увлечением было программирование. Именно он увлек группу студентов идеей реализации Алгола 68 – новейшего в ту пору алгоритмического языка высокого уровня [1]. Кроме того, под руководством Г.С. Цейтина в начале 70-х гг. мы реализовали один из первых в стране диалоговых редакторов текста dico [2].

               В 1974 году я познакомился с Б.А.Бабаяном, под фактическим руководством которого создавалась новая ЭВМ «Эльбрус». Нам поручили разработку интерпретатора Автокода «Эльбрус» на ЕС ЭВМ, ответственным исполнителем был Н.Ф. Фоминых [3,4]. Эта работа получила определенную известность. Поскольку выпуск «Эльбруса» задержался на несколько лет, нашим интерпретатором пользовались десятки коллективов по всему СССР. Некоторые важные заказчики расплачивались с нами фондами на ЕС ЭВМ – в те времена серьезная техника не продавалась свободно, а распределялась по фондам. Платить сотруднику больше полутора окладов было невозможно, поэтому нашим единственным интересом были те самые фонды. Мы говорили, что Коля Фоминых просидит где-то в глуши лесов, устанавливая интерпретатор и обучая как им пользоваться, а с ним расплатятся «борзыми щенками». Таким был наш первый опыт предпринимательства. Разумеется, ЭВМ получал ВЦ ЛГУ, но мы сумели договориться с руководством ВЦ, что «нашими» ЭВМ пользуемся только мы.

                С 1972 года заведовать кафедрой матобеспечения ЭВМ в ЛГУ стал чл.-корр. АН СССР Святослав Сергеевич Лавров. Под его руководством в 1975 году мы начали еще более крупную работу по программному обеспечению «Эльбруса» (отладочные средства и несколько десятков пакетов прикладных программ), я в это время уже руководил группой в лаборатории системного программирования ВЦ ЛГУ, наша группа совмещала работы по «Эльбрусу» и Алголу 68.

                 В 1976 году С.С. Лавров был избран на пост директора Института Теоретической Астрономии АН СССР, его активность в ЛГУ заметно снизилась, в конце концов, он оставил за собой только кафедру матобеспечения ЭВМ, а я был назначен и.о. руководителя большого отдела ВЦ, который был создан специально под работы по «Эльбрусу». Эти работы мы успешно завершили. В дальнейшем наш коллектив от работ по «Эльбрусу» отошел, а С.С Лавров продолжил со своими студентами, но по другим темам, например, трансляторы с АБВ и Паскаля.

                  К концу 70х годов работы по транслятору с Алгола 68 для ЕС ЭВМ вышли на заключительную фазу –комплексная отладка на ЕС ЭВМ [5]. Работа приобрела практический, производственный характер, в этот момент Г.С. Цейтин в значительной мере потерял к ней интерес. В течение 2-3х лет мы еще занимались под его руководством изучением и реализацией языков Искусственного Интеллекта и моделированием действий роботов, но большого интереса эти работы в нашем коллективе не вызвали.

                  В этот период нашим фактическим научным руководителем стал академик Андрей Петрович Ершов. Он возглавил рабочую группу по Алголу 68 ГКНТ СССР, я был назначен его заместителем. Мы собирались 4-5 раз в год в разных городах СССР, обсуждали проблемы реализации Алгола 68 для разных ЭВМ (в том числе, и для «Эльбруса»). Одновременно разрабатывалось несколько трансляторов с Алгола 68 под руководством Е.Л.Ющенко, А.Н.Маслова, М.Р.Левинсона, А.Н.Терехова и А.П.Ершова.

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

                 Ocенью 1976 года я в течение трёх месяцев читал лекции в Будапеште и привёз оттуда первые материалы по языку Ада и магнитную ленту с венгерской реализацией языка Пролог. Пролог мы изучили, выполнили несколько экспериментов, но нам декларативный способ не понравился, по крайней мере, на Прологе. Помню, как долго мы возились с задачей сборки деталей пирамидки из разбросанных на столе кружков разного диаметра. Сейчас я понимаю, что декларативный способ может быть с успехом использован, но только для определенного класса задач.

                 С языком Ада история интереснее. Мы ожидали, что Аду ждёт успех, поскольку это базовый язык Министерства обороны США. Я решил заняться реализацией языка Ада, используя накопленный опыт реализации Алгол 68. Но тут один из сотрудников нашей лаборатории Илья Гиндыш попросил меня отдать эту работу ему. Он на два года старше меня и ему также хотелось попробовать руководить темой. Я с некоторым сожалением согласился. Но уже через полгода руководителем этой темы в нашей лаборатории стал мой молодой выпускник Аркадий Попов. Так я в первый раз понял, что "полки не дают, полки берут". Аркадий Попов решил сделать всё "по науке", а не так, как мы работали над Алголом 68 (мы больше следовали технике быстрого прототипирования). Два года эта группа разрабатывала подробные спецификации, написали два или три толстых тома, но в первые же месяцы реализации натолкнулись на ошибку в проекте, 2 года работы пропали зря. Нет не зря! Мы получили бесценный личный опыт. В конце концов, эта группа завершила реализацию Ады и её окружения на ЕС ЭВМ, а затем и на ПЭВМ. Как и наш транслятор с Алгола 68, реализация языка Ада стала первой в СССР [6].

2. Работа с промышленностью

              В 1980 году оборонный отдел Обкома КПСС Ленинграда обратился к ректору ЛГУ В.Б.Алесковскому с просьбой о помощи, а он поручил мне курировать разработки в области ПО для военных заказов. Мне было сказано, что в оборонной промышленности столкнулись с массой проблем при создании ПО систем оборонного назначения, поэтому решено, что ЛГУ в лице нашей лаборатории должен помочь. Моего согласия никто не спрашивал, да в те времена этого и не требовалось. Так мы начали работать с ЛНПО "Красная Заря", "Импульс", "Морфизприбор", “Ленинец", "Аврора", "Гранит" –ведущими предприятиями Ленинграда, работающими в интересах различных родов войск и ведомств. С большинством этих предприятий мы работаем до сих пор.

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

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

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

               Многие пользователи годами писали программы на кем-то подготовленных для них специализированных языках, не подозревая, что они пишут на Алголе 68 и пользуются одним и тем же транслятором.

               Мы начали внедрять Алгол 68 в различные организации. Лучше всего получалось внедрение в военные организации, для которых требования надёжности превалировали над всеми остальными требованиями. Военные для своих задач чаще всего применяли не стандартные ЕС, СМ и персональные ЭВМ, для которых у нас трансляторы с Алгола 68 уже были реализованы, а специализированные ЭВМ (СЭВМ). Пришлось в массовом порядке заняться реализацией кросс-трансляторов.

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

3. HLL-компьютер «Самсон»

               Мы решили создать свою ЭВМ, следуя принципу «спасение утопающих -дело рук самих утопающих». Эта идея созревала очень долго.

                Во-первых, создавая ПО для «Эльбруса», мы прониклись идеей HLL-компьютеров (компьютеров, ориентированных на поддержку основных операторов АЯВУ). Мы любили отечественную ЭВМ «Эльбрус» и не любили «цельносоздранные» ЕС ЭВМ И СМ ЭВМ. Но нам не нравилось, что «Эльбрус» очень большой и требует водяного охлаждения, у этой ЭВМ главной задачей было обеспечение сверхвысокого быстродействия. За то, что мы сделали большой комплекс ПО для«Эльбруса», нам дали фонды на эту ЭВМ для мат-меха, который как раз в это время (1979 год) переехал в Петергоф. Мы построили зал площадью 500 квадратных метров, градирню (специальный бассейн для очистки воды), получили первые ящики с оборудованием, но тут университетские инженеры буквально взбунтовались. Они несколько раз съездили на завод–изготовитель, познакомились с правилами эксплуатации и заявили, что в университетских условиях обеспечить все необходимые требования невозможно. С огромным сожалением от идеи установки «Эльбруса» на мат-мехе пришлось отказаться.

               Во-вторых, следуя предложенной Н.Виртом идее Р-кода, которую он применял для переноса транслятора с языка Паскаль на разные ЭВМ (то, что у него была и аппаратная реализация в виде ЭВМ Lilith, мы тогда не знали), мы решили разработать полноценную архитектуру виртуальной ЭВМ. Тогда появились первые однобайтовые микропроцессоры 6502 и i8080 и первые персональные ЭВМ. Мы реализовали для них интерпретаторы нашей виртуальной ЭВМ и транслятор с Алгола 68 в её коды (Н.Н. Вояковская, Б.А. Федотов), получив возможность удобной работы в 16-разрядной архитектуре [7]. При замедлении в 4-5 раз мы в 2-3 раза выигрывали в длине объектного кода (за счёт более высокого уровня системы команд), что тогда было очень важно. Чаще всего, первые персональные ЭВМ имели только 64 кб оперативной памяти, но микропроцессоры уже были довольно быстрыми.

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

                Вначале мы решили сделать специализированный HLL- компьютер. В это время мы уже работали с ЛНПО «Красная Заря», хорошо знали УК1010, СУВК СС, СУВК СМ, «Нева» и другие СЭВМ, ориентированные на телекоммуникационные задачи. Но из идеи специализированного для телекоммуникационных задач HLL-компьютера ничего не вышло. Для установления соединения нужны логические команды, работа с битовыми шкалами, арифметика целых чисел. Для техобслуживания нужна работа со строками, файлы, диалог с оператором, сетевые возможности и т.д. Таким образом, нам нужна именно универсальная ЭВМ, несмотря на то, что она применяется в достаточно узкой предметной области.

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

                Решение этой задачи было подсказано нашим опытом разработки трансляторов. Сначала мы заметили, что существенную часть любой ЭВМ составляют схемы контроля, более того, мы видели ситуации, когда ЭВМ не работала именно из-за ошибок в схеме контроля. Отключаешь схему контроля –и всё в порядке! Потом мы заметили, что многие проверки, выполняемые аппаратурой, повторяют аналогичные проверки, которые перед этим делал транслятор с АЯВУ. Поскольку мы разрабатывали и архитектуру ЭВМ, и её системное ПО, мы решили, что подобная избыточность нам не нужна. Мы решили создать ЭВМ, для которой в принципе нельзя составлять программы на ассемблере, тем более, в кодах. Наша технологическая цепочка всегда включает трансляцию с АЯВУ, поэтому то, что проверил транслятор, аппаратура должна принимать "на веру". Зачем нужна проверка на неправильный код операции,неправильный номер регистра или некорректную адресацию, если транслятор такого не генерирует?

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

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

              Оказалось, что гарантировать корректную работу аппаратуры мы можем только для статических АЯВУ с полным контролем типов в период компиляции таких, как Алгол 68, Паскаль, Модула 2, Ада, но не таких, как С и PL/I. На этих принципах нам удалось создать компактную ЭВМ, мы дали ей имя "Самсон" [8], но не в честь сильного и легковерного библейского героя, а в честь самого большого фонтана у нас в Петродворце. Мы получили 3 авторских свидетельства (общая организация, совмещение регистров со стеком, организация виртуальной памяти), решили несколько интересных научных задач, привлекли в лабораторию много хороших студентов. Прежде чем был спаян хоть один провод, мы долго экспериментировали на моделях, отражающих потактовую структуру ЭВМ. Многие команды были включены в состав архитектуры именно в результате моделирования.

              Реализацией потактного симулятора занималась моя дочь Карина Терехова –тогда студентка младших курсов мат-меха. Мы с ней прогоняли сотни тестов, исследуя статическую и динамическую статистику использования разных команд и определяя, сколько тактов занимает исполнение того или иного теста. После каждого прогона теста мы брали только верхние по частоте 20-25 команд. Штук 5 команд исполнялись миллионы раз, следующие по частоте 10 команд –сотни тысяч раз, еще десяток –десятки тысяч раз, а остальные –сотни или тысячи раз, что для нас было неинтересно.

               Верхнюю строку всегда занимала команда «читать из памяти в стек целых» (40%). Нам удалось сделать однобайтовую команду, которая читала на стек одну из первых 15 переменных процедуры. Оказалось, что практически всегда только эта команда и используется, поскольку редко встречаются процедуры с большим числом локальных переменных.

               Каждый год на курсе «Архитектура ЭВМ» я рассказывал студентам, как, сидя на колхозном поле, обрубая хвостики морковки, я уговорил Колю Фоминых подумать, как сделать более эффективную реализацию этой команды. Коля полдня отнекивался, а потом все-таки придумал, как вместе 4 тактов сделать 3. Только за счет этого мы повысили производительность «Самсона» на 10%!

               Команда «условный переход по ложному условию» занимала 10% всех исполняемых команд (понятно почему –if,while), а команда «=» –8%. Мы их склеили (получив команду «переходпо равно») и выиграли 1 байт длины кода и 2 такта исполнения. Таких примеров можно привести множество. Само собой разумеется, из целей ортогональности и облегчения трансляции мы ввели команды «переход» по всем шести типам сравнений, хотя остальные команды использовались не так часто.

              Мы объездили несколько заводов в СССР с предложением наладить выпуск нашей машины. Но везде натолкнулись на отказ по той причине, что у нас не было западного прототипа. Такие тогда были времена. Нас выручил завод "Оргтехника"в г. Пловдиве (Болгария), который был побратимом Ленинграда. Все работы были оформлены как подарок к 70-летию советской власти, успешная демонстрация работы новой ЭВМ членам Политбюро БКП и нашим партийным начальникам состоялась 5 ноября 1987 года в 14 часов. В 12 часов "Самсон" еще не работал, мы не спали двое суток, под "горячую руку" попал даже наш ректор В.Б.Алесковский, о чем он со смехом напомнил мне через много лет.

              Болгары выпустили 100 экземпляров "Самсона", только после этого нам удалось убедить нашего основного заказчика в СССР –Управление правительственной связи КГБ. Для этого пришлось дополнительно разработать троированную архитектуру с очень высокой надёжностью. Но система команд была точно такая же, поэтому болгарский "Самсон" использовался как инструментальная ЭВМ.

              Собственно, идея троированного компьютера (три процессора, три памяти, три входных мажоритара и три выходных) принадлежит не нам. Нам была известна троированная ЭВМ «Микрон», созданная в НИИ АА под руководством академика В.С.Семенихина. Мы использовали такую же структурную схему, но вся реализация была своя.

              Очень важной идеей, которую мы реализовали в "Самсоне", было динамическое микропрограммирование. Н.Ф.Фоминых предложил удобную технологию микропрограммирования на Алголе 68 [9], которая в десятки раз упростила эту сложную задачу. Для стандартной системы команд "Самсона" мы занимали не более двух третей микропамяти, оставшуюся треть пользователи занимали для команд, придуманных специально для их приложений. Во многих случаях это позволяло ускорить критичные по времени фрагменты программы в 10-20 раз.

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

               Первой реализацией троированного управляющего вычислительного комплекса (УВК) «Самсон» была центральная ЭВМ АМТС «Фобос-К» Управления правительственной связи КГБ[10]. К сожалению, эта АМТС по причинам, весьма далеким от науки и техники, в серию не пошла. Тогда, воспользовавшись связями в Оборонном отделе Обкома КПСС, я договорился с ЛНПО «Импульс» о выпуске этого УВК. Сотрудники «Импульса» (особо надо упомянуть В.П.Самецкого и В.М.Зуева) переработали конструктив и отдельные элементы «Самсона» под свои требования, мы доработали инструментальные средства разработки. В 1992 году министр обороны России Грачев подписал приказ о принятии УВК «Самсон» на вооружение РВСН. Долгие годы это все было большим секретом, но в 1999 году РВСН праздновали свое 40-летие, к этому торжественному моменту была выпущена красочная толстая брошюра на мелованной бумаге. Первые 14 страниц посвящены УВК «Самсон», причем на 10-ой странице есть фраза «Архитектура и ОС УВК «Самсон» разработаны при помощи ГУП «Терком» и ЛГУ». Сначала эта фраза меня покоробила, но затем я осознал, что брошюра не содержит грифа, так что секрета больше нет. Теперь в курсе «Архитектура ЭВМ» я рассказываю студентам про HLL-компьютеры на примере УВК «Самсон». Я не думаю, что кто-то из моих выпускников будет на нем программировать, здесь главный интерес –как и почему всё это делалось. Часто перед рассказом какого-то раздела я спрашиваю у студентов, как бы они решили какую-то задачу построения архитектуры и иногда даже получаю ответы.

               Сейчас по заказу ФГУП «НИИ автоматики» (г. Москва) мы разрабатываем новый отказоустойчивый вычислительный комплекс (уже прошли испытания макета).

               Насколько мы знаем, "Самсон", принятый на вооружение в 1992 году, до сих пор активно используется во многих важных системах.

4. Технология

                Вернемся в самое начало 80х годов в ЛНПО «Красная Заря». Там в течение 15 лет никак не могли завершить работы по самому главному заказу правительственной связи «Кавказ-1». Меня назначили заместителем Главного конструктора по технологии программирования и поручили помочь в спасении этого «горящего» заказа.

                Как уже говорилось, мы, первым делом, попытались внедрить Алгол 68, в частности, реализовали кросс-транслятор в УК1010. Но начинать пришлось совсем не с этого, а с повышения общей культуры программирования разработчиков функционального программного обеспечения (ФПО) для СЭВМ. Дело в том, что нестандартность архитектуры и малая тиражность СЭВМ приводят к отсутствию достаточно развитых операционных систем, трансляторов, средств отладки и других, ставших уже привычными, инструментов программирования. Поэтому мы столкнулись с работой на перфокартах и непосредственно за пультом СЭВМ УК1010 "на тумблерах".

                Была сделана попытка воспользоваться известными в то время технологиями, однако, оказалось, что, например, Р-технология не имеет никаких средств настройки на СЭВМ, предлагаемые же в ней графический стиль программирования и программа-организатор с ручным вводом мало помогают в решении задач реального времени; технология РУЗА позволяет автоматизированным образом (но с большими ручными доработками) построить кросс-ассемблер нужной ЭВМ и интерпретатор ее системы команд, а также осуществить некоторую регламентацию работы (например, стандартизовать имена объектов). Р-технология была отвергнута практически сразу (за неимением конкретных программных средств на заданных нам СЭВМ), РУЗА в течение полугода была настроена на одну СЭВМ (УК1010), однако полностью учесть все особенности СЭВМ так и не удалось, кроме того, параметрически настраиваемые кросс-ассемблер и интерпретатор замедляют работу в 5-7 раз.

                Мы решили, что из-за таких простых программ, как ассемблер, не стоит "городить огород" и за короткое время реализовали новые кросс-ассемблер и интерпретатор УК1010, действующие на ЕС ЭВМ, которые вместе с текстовым документатором и некоторыми сервисными программами составили основу первой внедренной нами в производство (1984 год) технологической системы, интенсивно используемой сотнями разработчиков ФПО.

                В 1986 году «Кавказ-1» был успешно сдан. Разумеется, я не хочу сказать, что именно мы спасли этот заказ, там работали сотни людей, предпринимались жесткие меры, например, сменили Главного конструктора, но, надеюсь, и наш вклад был существенным. Некоторая неудовлетворенность все же осталась. Нам не удалось внедрить наши идеи полностью: во-первых, нас пригласили слишком поздно, во-вторых, мы не хотели влезать в секретные работы, занимались только технологией, а не самим ФПО. Часто программисты «Красной Зари» «забивали гвозди микроскопом», а потом говорили, что это наша технология виновата. Поэтому, когда начался следующий заказ «Фобос-К» того же заказчика, мы взяли на себя технологию программирования (на базе Алгола 68), ФПО и проектирование комплекса вычислительных средств (на базе «Самсона»), соединив, тем самым, три направления наших исследований, ранее развивавшихся независимо (трансляторы, технология, архитектура ЭВМ).

                На протяжении всей совместной работы сотрудников ЛГУ и "Красной Зари" боролись две точки зрения на предмет технологии программирования. Сотрудники ЛГУ, в основном, вкладывали в это понятие широкое использование инструментальных средств, а сотрудники "Красной Зари" настаивали на том, что технология -это, прежде всего, набор формальных методик и регламентирующих средств, позволяющих, в частности, на каждом этапе провести экспертизу, архивацию и измерение объема и качества проделанной работы. Такой подход вызывал постоянное раздражение профессиональных программистов.

               Только после двух-трёх лет работы в промышленности мы осознали, что нельзя всё сводить к программному инструментарию. Поначалу мы с гневом отказывались от требований начальства детально документировать, кто, что и за какой период написал, но оказалось, что в большом коллективе всегда находятся милые в общении, всеми любимые активисты всевозможных мероприятий, которые вообще ничего не делают по работе. Первую сдачу проекта для правительственной связи я завалил, так как буквально перед самой сдачей кто-то украл одну (!) перфокарту, а эти товарищи всегда начинали с чистой машины и полной перетрансляции. Вредителя так и не нашли, зато я получил хороший урок. Мы быстро реализовали контрольно-учётные программы, архивы с контролируемым доступом, многоуровневые системы сбора версий ПО и тому подобные "шпионские штучки". Так я впервые осознал разницу между "программированием для себя" и "программированием для хозяина", о которых так красочно говорил академик А.П. Ершов.

               Проектирование систем реального времени –очень сложная задача, причем трудности носят скорее «человеческий», а не технический характер, то есть проблемы возникают не из-за недостаточной квалификации кого-либо из участников разработки, а из-за взаимного недопонимания. Слишком много людей вовлечено в решение этой задачи – алгоритмисты, специалисты по протоколам, программисты, инженеры-электронщики и другие.Для преодоления этих трудностей Международный Консультационный Комитет по Телеграфии и Телефонии (ныне ITU-T) разработал серию графических языков, в частности, SDL (спецификация Z.100) [11] и MSC (спецификация Z.120) [12].

              SDL(SpecificationandDescriptionLanguage) диаграмма очень похожа на традиционные блок-схемы, но с несколькими важными расширениями: символ состояния, в котором процесс не занимает процессор, ожидая приема одного или нескольких сигналов; символ приема сигнала и символ посылки сигнала. Эти расширения позволяют удобным образом описывать параллельные процессы.

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

               Мы разработали конвертор из SDL-диаграмм в Алгол 68, систему имитационного моделирования, различные отладчики, средства для снятия и анализа трасс, другие инструменты, которые обеспечили первые практические применения SDL-диаграмм. Первым успешным проектом, разработанным по нашей технологии, стал «Фобос-К».

               В начале 90-х годов мы перевели все технологические средства на ПЭВМ, а заодно начали использовать объектно-ориентированный подход к проектированию ПО. Нам удалось найти эффективную реализацию вычислительного процесса для систем реального времени[13]; усилить различные статические проверки, например, если сигнал не упомянут в описании объекта, то его невозможно использовать в SDL диаграммах; разработать средства автоматической генерации данных и так далее.

               Под именем RTST (Real Time Software Technology) [14] эта технология просуществовала около 10 лет, с ее помощью были разработано более 10 типов различных телефонных станций и несколько других программно-аппаратных средств, причем 70-80% SDL диаграмм легко переносились с одной платформы на другую. Существенно было облегчено сопровождение ПО, введение в коллектив новых специалистов, переиспользование фрагментов, короче, мы убедились в преимуществах промышленных графических технологий.

               Однако постепенно пришло понимание и недостатков RTST. Прежде всего, оказалось, что трудно сразу создать описание классов, да ещё в текстовом виде. Мы уже начали продумывать графические формы для описания проектируемой системы на этапах раннего моделирования, но тут появился UML[15]. Мы были знакомы с подходами, которые до этого предлагали Буч, Рэмбо и Якобсон по отдельности, но каждый из них охватывал только отдельные фазы жизненного цикла проектирования ПО. Интеграция этих подходов в едином графическом языке UMLкоренным образом изменила ситуацию, особенно на начальных этапах проектирования. С другой стороны, в 90-х годах UMLне имел практически никаких средств для задания детальных алгоритмов. Мы решили использовать наш опыт и объединить подходы UMLи SDLв единой технологии [16]. Новая технология получила название REAL–с одной стороны, хотелось подчеркнуть преемственность с RTSTи системами реального времени, с другой стороны, мы надеялись, что новая технология окажет реальную помощь создателям ПО.

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

              Второе направление связано с проектированием информационных систем. Лидером этого направления у нас является Александр Иванов [17], который придумал и реализовал средства автоматической генерации различных форм ввода и вывода информации, средства разграничения прав доступа, учета связей между различными атрибутами и т.д. В этом варианте технологии главной является диаграмма классов. По ней автоматически строится описание базы данных на языке DDL(DataDefinitionLanguage), программы CRUD(create, read, update, delete, т.е. создать, прочитать, исправить, удалить), API(ApplicationProgramInterface–интерфейс программных приложений) для работы с реляционной базой данных как с объектно-ориентированной. По этой же диаграмме генерируются программы работы с визуальными формами, а с помощью диаграммы объектов задаются связи между атрибутами и ограничения прав доступа.

               Программа «Студент»[18], автоматизирующая деятельность деканатов и ректората нашего университета (а также многих других университетов) практически полностью автоматически сгенерирована, только очень малый процент подпрограмм был написан вручную на VisualBasic.

5.Организационные структуры

                Первые годы мы взаимодействовали с промышленностью традиционным для университета способом –через хозяйственные договора. Но оказалось, что это сильно затрудняет работу: послать сотрудника в командировку к Гензаказчику трудно, выписать пропуск в оборонное предприятие трудно, выплатить деньги за дополнительную работу –тоже трудно. В те годы основным связующим звеном между нами и промышленностью был капитан 1го ранга, доктор технических наук В.П.Морозов. Ещё до работы с нами он прославился тем, что под его руководством были созданы какие-то очень важные программные комплексы для ВМФ, но и он понял, что его «командные» методы имеют свои ограничения, плохо масштабируются. Поэтому В.П. Морозов горячо поддержал идею взаимодействия с Университетом (возможно, он и был инициатором этого). Авторитет у него был огромный –вплоть до ЦК КПСС. Именно В.П. Морозов предложил и за несколько месяцев осуществил идею создания совместного комплексного отдела Минпромсвязи СССР и Министерства образования РСФСР. Когда два министра в 1987 году утвердили положение об этом отделе, дела пошли быстрее, например, наш парк вычислительной техники был мощнее ВЦЛГУ, да и зарплаты у нас существенно выросли. Не все в Университете смогли это спокойно вынести, доходило до курьезов. Например, как-то раз меня «пропесочило» партбюро мат-меха по жалобе одного ученого, что, мол, 10 Терехов обедняет мат-мех, забирая себе лучших студентов, привлекая их возможностью работать на самой современной технике. Выслушав эти претензии, я хмыкнул, что в соответствии с этой жалобой у меня лучшая лаборатория на мат-мехе (лучшая техника, лучшие студенты, самое большое финансирование), поэтому меня надо не порицать, а объявлять благодарность. Пусть этот ученый возьмет на себя пару-тройку оборонных заказов, успешно их выполнит, тогда он сможет конкурировать со мной за лучших студентов. В конце концов, партбюро согласилось с моими доводами, но я хорошо понимал, что играю с огнём –разборки в партбюро тогда часто плохо кончались.

                В 1987 году мы с В.П.Морозовым создали НИИ «Звезда», вошедшее в ЛНПО «Красная Заря». В этом НИИ я получил должность «заместитель директора по перспективным научным исследованиям», эту должность мы придумали специально для меня, так как на всех «стандартных» должностях нужно было работать на полную ставку, а я ни за что не хотел уходить из Университета, но был согласен на работу по совместительству. Также поступили и все остальные сотрудники лаборатории системного программирования.

                 С  В.П.Морозовым связано ещё одно важное для меня воспоминание. Со времени образования комплексного отдела у нас сложилась традиция –каждую субботу мы встречались у него дома, где я в течение 5-6 часов рассказывал ему о наших предыдущих исследованиях. В.П.Морозов был великим педантом, все рассказы он протоколировал на миллиметровке в им придуманной форме. В качестве примеров он мне показывал записи десяти-и двадцатилетней давности. Он сразу же составлял план реализации каждой нашей идеи. Поначалу я в это не очень верил, мне казалось, что даже при всех возможностях, его обещания за две недели получить новую мощную ЭВМ, выбить финансирование на НИР по нашей идее, получить заказ на воплощение в жизнь уже проработанной идеи и т.д. – попахивают фантазерством. Но все обещания В.П.Морозова выполнялись. У меня появился чисто спортивный интерес –не пропустить какой-то нашей идеи, разработки, часто даже на довольно далекие от нашей текущей работы темы. Всё шло в ход, пользуясь нашими связями с оборонным отделом, мы легко выходилина руководство разных оборонных предприятий и обычно находили там понимание и сторонников.

              Так вот, через 3-4 года наших регулярных субботних встреч я с ужасом обнаружил, что мне нечего В.П.Морозову рассказать. Мы работали как черти, одновременно внедряли кросс-трансляторы, технологии, ЭВМ «Самсон» и различные специализированные устройства, но работы на перспективу как-то незаметно отошли на второй план. Я даже представить себе не мог, что нас можно так быстро иссушить. Этот урок я запомнил на всю жизнь. С тех пор, какая бы важная работа у нас не была, какие бы мы ни использовали финансовые трудности, я всегда трачу часть ресурсов (в последние годы даже личных денег) на поддержание исследований на перспективу.

               К началу 90-ых годов ситуация в стране ухудшились, наши традиционные заказчики перестали финансировать даже вполне прикладные исследования, НИИ «Звезда» вырос до 300 сотрудников, как мы говорили, «забюрократизировался». Чтобы сохранить дееспособное ядро, мы решили в соответствии с модой того времени создать малое государственное предприятие примерно в том же составе, что и совместный комплексный отдел. В.П.Морозов эту идею поддержал, НИИ «Звезда» выступил учредителем. Тогда мы все были абсолютно убеждены, что «смутные времена» закончатся через 2-3 года, поэтому создание МГП мы рассматривали как вынужденную временную меру, даже название ему придумали шуточное –«Терком», т.е. Терехов и его команда.

6. Терком и итальянцы

               Итак, 14 февраля 1991 года МГП «Терком» было зарегистрировано и начало жить самостоятельной жизнью. Первоначально туда перешли на постоянную работу 30 человек. Я, как всегда, работал генеральным директором по совместительству. Никакого начального финансирования у нас не было. Я читал лекции в Гамбурге и за месяц получил 4000 DM, каждому сотруднику раздал по 100 DM, тогда на эти деньги можно было прожить месяц.

               Первый маленький заказ мы получили под работы Петра Лаврова по модификации «Кавказа 1». Нам обещали крупный заказ по «Фобос-К», но его оформление затягивалось. 19-го августа в 6 утра меня разбудили сообщением о путче. Моя жена Галия и Борис Федотов пошли протестовать на Исаакиевскую площадь (до обеда 19 августа там было меньше 100 человек, окруженных несколькими тысячами омоновцев), а я поехал подписывать договор (и подписал!) с ФАПСИ – осколком КГБ. До сих пор моя жена подтрунивает надо мной, вспоминая 19 августа, но 30 голодных ртов, которым ты несколько месяцев не платил зарплату, –это тяжелый груз.

               Опыта работы директором у меня не было. Например, я с большим удивлением узнал, что на 3-ехлетнюю тему тебе дают 50% денег авансом, а расчет только по окончании темы. Как ты будешь платить зарплату во второй половине срока – это твое дело. Стало ясно, что работать по одному, даже очень большому заказу, нельзя, надо иметь несколько одновременно идущих договоров, чтобы иметь оборотные средства.

               Уже тогда у нас появились большие сомнения в стабильности государственных заказов, поэтому мы стали пытаться найти зарубежных заказчиков. Первого такого заказчика нам помогла найти та же «Красная Заря». В 1992 году крупнейшая итальянская телекоммуникационная компания ITALTEL сама захотела наладить сотрудничество с крупнейшим производителем телефонных станций в СССР «Красной Зарей». На встречу с итальянской делегацией Ю.Г.Данилевский пригласил человек 20 начальников отделов и, к счастью, меня. Краснозаревцы работали, в основном, по секретным заказам, до этого им общаться с иностранцами вообще было запрещено, никто не говорил по-английски. Правда, несколько человек имели опыт работы с МККТТ и с французами по телефонной станции МТ20 (Г.С.Истомин, С.Г.Гундарев). Мне было существенно легче, я хорошо говорю по-английски, несколько раз бывал в западных странах, поэтому не был так скован. Когда же я упомянул, что работаю в Университете и руковожу лабораторией системного программирования, итальянцы сразу же захотели съездить к нам в Петергоф. Ю.Г.Данилевский даже обиделся, что я «перетягиваю одеяло на себя», но руководитель итальянской делегации М.Морганти его успокоил, пообещав, что большой кусок работы отдаст «Красное Заре» (и сдержал обещание). Мы же договорились, что будем проектировать устройства и разрабатывать встроенное ПО реального времени. Тут необходимо упомянуть, что в 1991 году я защитил докторскую диссертацию на тему «Технологии программирования встроенных систем реального времени». Этот факт мне сильно помог в переговорах с итальянцами, типичный «рояль в кустах». Итальянцы первыми начали учить нас проектировать кристаллы, наш сотрудник Борис Кривошеин прошел обучение в школе НАТО (как сотрудник ITALTEL), а потом обучал других наших инженеров.

                Здесь также надо вспомнить одну поучительную историю. Итальянцы нам заказали разработку SetTopBox–устройства, которое обеспечивает связь с Интернет, используя вместо дисплея домашний телевизор. Мы все сделали в лучшем виде, меня пригласили в Милан для подписания следующего контракта и с гордостью показали огромный ящик, набитый нашими платами. Оказалось, что их целью был вовсе не SetTopBox, а АТМ-коммутатор. Они опасались делиться с нами коммерческими секретами, поэтому работали с нами «втёмную». Я им быстро объяснил, что они сделали нечто дико избыточное, например, на каждой нашей плате стоит микропроцессор M68000 с обрамлением, а для целей коммутатора это совершенно не нужно. Они согласились, извинились и тут же заказали нам разработку АТМ-коммутатора «с нуля». Мы и с этим справились. Кажется, это был первый АТМ-коммутатор в Европе, он до сих пор эксплуатируется в сети PEAN. Мы разработали и реализовали и аппаратные средства, и программное обеспечение коммутатора, но, что ещё более важно, реализовали и программные средства управления гетерогенными сетями связи. Насколько я знаю, никто в России до сих пор средств АТМ в полном объеме не разработал.

               Наше сотрудничество с ITALTEL развивалось очень успешно, мы занимались передовыми исследованиями, использовали самые новые технологии, публиковали статьи, защищали диссертации. Но всё закончилось самым неожиданным образом. Компания Siemens выкупила 50% акций ITALTEL, а потом оказалось, что немцы просто хотели убить одного из конкурентов. Компания, в которой работало 17 тысяч сотрудников, практически перестала существовать.Одно дело –слушать лекции по марксизму-ленинизму про «гримасы капитализма», но совсем другое – столкнуться с этим в реальной жизни. Мы все были просто в шоке.

              Наши коллеги-итальянцы в благодарность за долгое успешное сотрудничество передали нам всё дорогостоящее ПО и оборудование, а также права на интеллектуальную собственность результатов разрабатываемых нами совместно НИР. Даже через 10 лет наши сотрудники защищают диссертации по темам, которые были начаты совместно с итальянцами, например, CoDesign – разработка процессора, оптимизированного на заданный класс задач [Булычев].

               Чтобы не заканчивать рассказ про наше сотрудничество с итальянцами на столь грустной ноте, расскажу ещё одну забавную историю. В один из моих приездов в Милан мне устроили экскурсию в «святая-святых» ITALTEL –бизнес-юнит, разрабатывающий основное ПО. Моим экскурсоводом была такая маленькая и веселая итальянка миссис Тутси. Она с гордостью показывала мне их совершенные графические технологии, на мой взгляд, существенно слабее наших. Но, как вежливый гость, я помалкивал. Не удержался я только один раз, когда спросил: «Как же так, у вас описание делается на одном языке (SDL-PR), а поведение описывается на другом (C-SDL)? Если кто-то по ошибке для одной и той же сущности даст противоречивые описания, то кто найдет эту ошибку?». Тут эта маленькая женщина схватила меня за грудки и стала требовать, чтобы я признался, кто выдал этот важный коммерческий секрет, свидетельствующий о потенциальной слабости их ПО. Мне стоило большого труда объяснить, что я не шпион, а профессор, и что я читаю студентам лекции на эту тему. В хорошей технологии все описания должны браться из одного источника, чтобы обеспечить их непротиворечивость.

7. Терком и американцы

               Примерно в конце 1992 года через одного бывшего ленинградца (а в то время уже американца) мне в руки попало письмо от американской компании Seer Technologies с приглашением принять участие в проекте по реинжинирингу устаревших программных систем. На самом деле, это письмо не было адресовано мне или нашей компании, они уже сделали несколько попыток как в США, так и в России. Американская бизнес-идея выглядела очень привлекательной: в мире накоплены тонны программ, написанных на Cobol, PL/1, Adabas Natural и других устаревших языках. Эти программы успешно эксплуатируются более 10-20 лет, причем в критически важных областях (оборона, финансы, здравоохранение и т.п.), но их сопровождение с каждым годом становится всё дороже. Авторы программ уже не работают в данной фирме, университеты не готовят специалистов по старым языкам, никто не поддерживает технологии, с помощью которых это ПО было реализовано. Самое страшное, из-за многочисленных изменений, сделанных в ПО за долгие годы эксплуатации, документация не отражает реальное положение дел. Таким образом, единственным источником реальной информации о программе является её исходный код (текст программы). А поскольку американцы всегда славились своей приверженностью к методу «грубой силы», то приложение объемом 4-5 млн строк, состоящее из модулей по 40-60 тыс.строк на 10-15 разных языках, не является редкостью.

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

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

               Получившийся в результате продукт Rescue Ware в 2000 и 2001 годах Gartner Group признавала лучшим в области Legacy Understanding и Legacy Transformation1.Был период,когда над этим продуктом у нас работало более 100 человек. Мы получили неоценимый опыт разработки программного продукта (а не традиционного для нас сервисного программирования на заказ), настоящей промышленной разработки с выходом на американский рынок. Не обошлось и без скандалов и курьезов.

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

               Американцы устроили настоящий скандал. Они боялись, что продукт, сделанный в России, никто не купит. Пришлось занять жесткую позицию. Я специально летал в Северную Каролину и объяснил им, что мы люди университетские, нам надо публиковаться, защищать диссертации, иначе мы выходим из контракта, пусть они ищут других математиков, которые смогут решить эту задачу. Тогда американцы сменили позицию на 180 градусов, стали везде говорить, что такой продукт смогли сделать только гениальные русские математики, устроили нам интервью по CNN в 19 часов лондонского времени, интервью Associated Press, часовое выступление в клубе журналистов в Вашингтоне и т.д. Часто мы себя чувствовали даже неловко, но уж лучше так, чем вообще нас не упоминать.

                 Другой случай связан с Андреем Тереховым младшим, который вместе с голландцем C.Verhoef получил премию за лучшую статью по Коболу в 2000 году. В этой статье авторы описывали трудные места семантики Кобола и показывали невозможность «лобовой» трансляции Кобола в современные языки с сохранением семантики. Опять американцы скандалят, что в этой статье, мол, доказывается невозможность Rescue Ware. Мне пришлось снова лететь в Америку и объяснять, что,наоборот, в этой статье показано, сколько трудностей пришлось преодолеть в процессе реализации Rescue Ware и что никто из конкурентов этого сделать не сможет. Вообще, я в Америке был более 15 раз и уверен, что самая частая фраза там: «Я на тебя в суд подам», хотя бизнес там активный и быстрый, не такой, как, скажем, в Германии, где ни одного контракта быстрее, чем за год не подпишешь. 

¹ Кстати, в 2003 году мы ещё раз были лучшими в этих областях, но уже с другим американским заказчиком.

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

8. Ланит-Терком

               В 1995 году из российского законодательства исчезло понятие «МГП», мы перерегистрировались в государственное унитарное предприятие Терком. В этот моменту у нас работало более ста человек, мы стали задумываться, зачем нам это надо. Государственных заказов мы уже не имели, американцы всё время ворчали, что не хотят в нашем лице кормить государство, прибыль мы всю реинвестировали. Сильное давление на меня оказывал А.Терехов (мл.), существенно более бизнес-ориентированный. Лично я к этому времени так ничего и не заработал, а начинать с нуля еще раз не хотелось. Мы стали искать инвестора. Кто только не предлагал нам большие деньги, даже производители водки, но нам казалось это опасным. Были и серьезные предложения, но с условием, что мы станем торговать ПО и компьютерами, а это означало, что надо полностью сменить наш профиль.

               В первые годы я не задумывался о таких философских проблемах, как лицо нашего предприятия, его профиль. Мы брались за такие работы, которые нам казались близкими к нашей специальности, которые были нам интересны. Часто оказывалось, что нам доставались такие задачи, за которые никто другой браться попросту не хотел. Постепенно я осознал, что просто программистов в нашем городе, России, да и вообще в мире«пруд пруди», надо обязательно иметь какую-то особенность, которая позволит тебе выделиться, показать потенциальным заказчикам, почему работать надо именно с этим предприятием, а не с многими другими. В те годы все российские компании напирали на дешевизну нашей рабочей силы, но это преимущество быстро улетучилось. Я решил сосредоточиться на наукоемком программировании, до сих пор нашим лозунгом является «smartsoftwaresolutions». Многие мои молодые сотрудники спорили с этим, говорили, что мы сужаем пространство наших вероятных заказчиков. Сейчас, когда на дворе кризис (начало 2009 года) именно наукоемкие заказчики сохранили свой бизнес и расширяют сотрудничество с нами.

Литература

1.Алгол 68. Методы реализации. Под ред. Г.С. Цейтина. –Л.: Изд-во Ленинградского университета, 1976г., 224с.

2.С.Н. Баранов, А.Н.Терехов, Г.С. Цейтин «Инструкции к программе DICO»,Методические материалы по программному обеспечению ЭВМ. Серия 4. Выпуск 5.Изд.ЛГУ, 1974г.

3.Н.Ф.Фоминых"Интерпретатор автокода МВК "Эльбрус" для ЕС ЭВМ",диссертация на соискание ученой степени кандидата физико-математических наук, Ленинград, 1987 г.

4. Гиндыш И.Б., Попов А.П., Рухлин А.П., Терехов А.Н., Фоминых Н.Ф., Швецова Г.А. "Интерпретатор АК ЛГУ для ЕС ЭВМ", изд.ЛГУ, 1981 г.

5.Дейкало Г.Ф., Новиков Б.А., Рухлин А.П., Терехов А.Н. "Новые средства программирования для ЕС ЭВМ. Транслятор с языка Алгол 68 и диалоговая система JEC", "Финансы и статистика", М., 1984г.

6.Попов А. П. "Методы реализации языка Ада", диссертация на соискание ученой степени кандидата физико-математических наук, Ленинград, 1987 г.

7.Матиясевич Ю.В., Терехов А.Н., Федотов Б.А."Унификация программного обеспечения микроЭВМ на базе виртуальной машины","Автоматика и телемеханика", N5, Москва, 1990 г.

8.Евстюнин М.В., Кожокарь С.К., Терехов А.Н., Уфнаровский В.А. "Как Паскаль и Оберон попадают на "Самсон",Монография по технике программирования. Кишинев, "Штиинца", 1992 г.

9.Н.Ф.Фоминых, Использование стандартного расширяемого алгоритмического языка в микропрограммировании. Всб.: Диалоговыемикрокомпьютерныесистемы. М., МГУ, 1986 г.

10. С.А.Валдаев «Связь, которая не подведет», М., Славянский диалог, 2001 г.

11.CCITT Recommendation Z.100: CCITT Specification and Description Language (SDL) // COM X-R 26, ITU General Secretariat, Geneva, 1992.

12.ITURecommendationZ.120: MessageSequenceChart. 11/1999.P.138

13.А.Н.Терехов "RTST -технология программирования встроенных систем реального времени", Сб. "Записки семинара кафедры системного программирования "CASE-средства RTST++". Вып.1,СПб, Издательство СПбГУ, 1998 г.

14. Парфенов В.В., Терехов А.Н. "RTST -технология программирования встроенных систем реального времени", Cб. "Системная информатика", Вып.5. Новосибирск, Сибирская издательская фирма РАН, 1997г.

15. UMLSpecificationversion1.1 (OMGdocumentad/97-08-11)

16. А.Н.Терехов, К.Ю.Романовский, Дм.В.Кознов, П.С.Долгов, А.Н.Иванов. Real: методология и CASE-средство для разработки систем реального времени и информационных систем//Программирование,1999г., No5, с.44-52

17.А.Н.Иванов. Технологическое решение REAL-IT: создание информационных систем на основе визуального моделирования. Системное программирование. Сб. статей/ Под.ред. А.Н.Терехова и Д.Ю.Булычева. –Спб., 2004г., с.89-100

18.Стригун С.А., Иванов А.Н., Соболев Д.И. Технология REALдля создания информационных систем и ее применение на примере системы «Картотека».//Математические модели и информационные технологии в менеджменте. Выпуск 2./ Под ред. проф. Казанцева А.К. и доц. Должикова В.В. –СПб:Издательство Санкт-Петербургского университета, 2004г.,с.120-139

УВК «Самсон»- базовая ЭВМ РВСН

    1.Введение

Коллектив сотрудников  лаборатории системного программирования ВЦ ЛГУ всегда состоял только из математиков–выпускников мат-меха ЛГУ. Но именно в этой лаборатории была разработана новая ЭВМ, не являющаяся копией какой-то иностранной ЭВМ, хотя это было очень принято в СССР в те годы. Разумеется, после того, как все было придумано и отмоделировано, мы пригласили группу инженеров для еѐ воплощения «в железе», но не было ни одного случая, когда какое-нибудь решение было принято инженерами против воли математиков –это была главная идея проекта.

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

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

   2.Трансляторы

             Я закончил мат-мех ЛГУ с отличием в 1971 году (первым защитил диплом в первом выпуске кафедры матобеспечения ЭВМ). Моим научным руководителем был доктор физ.-мат. наук Григорий Самуилович Цейтин –сильный и разносторонний ученый. В то время он руководил лабораторией матлингвистики НИИММ ЛГУ, достиг выдающихся успехов в матлогике и теории сложности вычислений, но основным его увлечением было программирование. Именно он увлек группу студентов идеей реализации Алгола 68 –новейшего в ту пору алгоритмического языка высокого уровня [1]. Кроме того, под руководством Г.С.Цейтина в начале 70-х гг. мы реализовали один из первых в стране диалоговых редакторов текста dico [2].

               В 1974 году я познакомился с Б.А.Бабаяном, под фактическим руководством которого создавалась новая ЭВМ «Эльбрус». Нам поручили разработку интерпретатора Автокода «Эльбрус» на ЕС ЭВМ, ответственным исполнителем был Н.Ф. Фоминых [3,4]. Эта работа получила определенную известность. Поскольку выпуск «Эльбруса» задержался на несколько лет, нашим интерпретатором пользовались десятки коллективов по всему СССР. Некоторые важные заказчики расплачивались с нами фондами на ЕС ЭВМ –в те времена серьезная техника не продавалась свободно, а распределялась по фондам. Платить сотруднику больше полутора окладов было невозможно, поэтому нашим единственным интересом были те самые фонды. Мы говорили, что Коля Фоминых просидит где-то в глуши лесов, устанавливая интерпретатор и обучая как им пользоваться, а с ним расплатятся "борзыми щенками". Таким был наш первый опыт предпринимательства. Разумеется, ЭВМ получал ВЦ ЛГУ, но мы сумели договориться с руководством ВЦ, что "нашими" ЭВМ пользуемся только мы.

            С 1972 года заведовать кафедрой матобеспечения ЭВМ в ЛГУ стал чл.-корр. АН СССР Святослав Сергеевич Лавров. Под его руководством в 1975 году мы начали еще более крупную работу по программному обеспечению «Эльбруса» (отладочные средства и несколько десятков пакетов прикладных программ), я в это время уже руководил группой в лаборатории системного программирования ВЦ ЛГУ, наша группа совмещала работы по «Эльбрусу» и Алголу 68.

             В 1976 году С.С. Лавров был избран на пост директора Института Теоретической Астрономии АН СССР, его активность в ЛГУ заметно снизилась, в конце концов, он оставил за собой только кафедру матобеспечения ЭВМ, а я был назначен и.о. руководителя большого отдела ВЦ, который был создан специально под работы по «Эльбрусу». Эти работы мы успешно завершили. В дальнейшем наш коллектив от работ по «Эльбрусу» отошел, а С.С Лавров продолжил со своими студентами, но по другим темам, например, трансляторы с АБВ и Паскаля.

               К концу 70х годов работы по транслятору с Алгола 68 для ЕС ЭВМ вышли на заключительную фазу –комплексная отладка на ЕС ЭВМ [5]. Работа приобрела практический, производственный характер, в этот момент Г.С. Цейтин в значительной мере потерял к ней интерес. В течение 2-3х лет мы еще занимались под его руководством изучением и реализацией языков Искусственного Интеллекта и моделированием действий роботов, но большого интереса эти работы в нашем коллективе не вызвали.

               В этот период нашим фактическим научным руководителем стал академик Андрей Петрович Ершов. Он возглавил рабочую группу по Алголу 68 ГКНТ СССР, я был назначен его заместителем. Мы собирались 4-5 раз в год в разных городах СССР, обсуждали проблемы реализации Алгола 68 для разных ЭВМ (втом числе, и для «Эльбруса»). Одновременно разрабатывалось несколько трансляторов с Алгола 68 под руководством Е.Л.Ющенко, А.Н.Маслова, М.Р.Левинсона, А.Н.Терехова и А.П.Ершова.

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

               Ocенью 1976 года я в течение трѐх месяцев читал лекции в Будапеште и привѐз оттуда первые материалы по языку Ада и магнитную ленту с венгерской реализацией языка Пролог. Пролог мы изучили, выполнили несколько экспериментов, но нам декларативный способ не понравился, по крайней мере, на Прологе. Помню, как долго мы возились с задачей сборки деталей пирамидки из разбросанных на столе кружков разного диаметра. Сейчас я понимаю, что декларативный способ может быть с успехом использован, но только для определенного класса задач.

               С языком Ада история интереснее. Мы ожидали, что Аду ждѐт успех, поскольку это базовый язык Министерства обороны США. Я решил заняться реализацией языка Ада, используя накопленный опыт реализации Алгол 68. Но тут один из сотрудников нашей лаборатории Илья Гиндыш попросил меня отдать эту работу ему. Он на два года старше меня и ему также хотелось попробовать руководить темой. Я с некоторым сожалением согласился. Но уже через полгода руководителем этой темы в нашей лаборатории стал мой молодой выпускник Аркадий Попов. Так я в первый раз понял, что "полки не дают, полки берут". Аркадий Попов решил сделать всѐ "по науке", а не так, как мы работали над Алголом 68 (мы больше следовали технике быстрого прототипирования). Два года эта группа разрабатывала подробные спецификации, написали два или три толстых тома, но в первые же месяцы реализации натолкнулись на ошибку в проекте, 2 года работы пропали зря. Нет не зря! Мы получили бесценный личный опыт. В конце концов, эта группа завершила реализацию Ады и еѐ окружения на ЕС ЭВМ, а затем и на ПЭВМ. Как и наш транслятор с Алгола 68, реализация языка Ада стала первой в СССР [6].

   3. Работа с промышленностью

              В 1980 году оборонный отдел Обкома КПСС Ленинграда обратился к ректору ЛГУ В.Б.Алесковскому с просьбой о помощи, а он поручил мне курировать разработки в области ПО для военных заказов. Мне было сказано, что в оборонной промышленности столкнулись с массой проблем при создании ПО систем оборонного назначения, поэтому решено, что ЛГУ в лице нашей лаборатории должен помочь. Моего согласия никто не спрашивал, да в те времена этого и не требовалось. Так мы начали работать с ЛНПО "Красная Заря", "Импульс", "Морфизприбор", “Ленинец", "Аврора", "Гранит" –ведущими предприятиями Ленинграда, работающими в интересах различных родов войск и ведомств. С большинством этих предприятий мы работаем до сих пор.

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

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

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

             Многие пользователи годами писали программы на кем-то подготовленных для них специализированных языках, не подозревая, что они пишут на Алголе 68 и пользуются одним и тем же транслятором.

             Мы начали внедрять Алгол 68 в различные организации. Лучше всего получалось внедрение в военные организации, для которых требования надѐжности превалировали над всеми остальными требованиями. Военные для своих задач чаще всего применяли не стандартные ЕС, СМ и персональные ЭВМ, для которых у нас трансляторы с Алгола 68 уже были реализованы, а специализированные ЭВМ (СЭВМ). Пришлось в массовом порядке заняться реализацией кросс-трансляторов.

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

    4. HLL-компьютер «Самсон»

             Мы решили создать свою ЭВМ, следуя принципу «спасение утопающих -дело рук самих утопающих». Эта идея созревала очень долго.

              Во-первых, создавая ПО для «Эльбруса», мы прониклись идеей HLL-компьютеров (компьютеров, ориентированных на поддержку основных операторов АЯВУ). Мы любили отечественную ЭВМ «Эльбрус» и не любили «цельносоздранные» ЕС ЭВМ И СМ ЭВМ. Но нам не нравилось, что «Эльбрус» очень большой и требует водяного охлаждения, у этой ЭВМ главной задачей было обеспечение сверхвысокого быстродействия. За то, что мы сделали большой комплекс ПО для «Эльбруса», нам дали фонды на эту ЭВМ для мат-меха, который как раз в это время (1979 год) переехал в Петергоф. Мы построили зал площадью 500 квадратных метров, градирню (специальный бассейн для очистки воды), получили первые ящики с оборудованием, но тут университетские инженеры буквально взбунтовались. Они несколько раз съездили на завод–изготовитель, познакомились с правилами эксплуатации и заявили, что в университетских условиях обеспечить все необходимые требования невозможно. С огромным сожалением от идеи установки «Эльбруса» на мат-мехе пришлось отказаться.

             Во-вторых, следуя предложенной Н.Виртом идее Р-кода, которую он применял для переноса транслятора с языка Паскаль на разные ЭВМ (то, что у него была и аппаратная реализация в виде ЭВМ Lilith, мы тогда не знали), мы решили разработать полноценную архитектуру виртуальной ЭВМ. Тогда появились первые однобайтовые микропроцессоры 6502 и i8080 и первые персональные ЭВМ. Мы реализовали для них интерпретаторы нашей виртуальной ЭВМ и транслятор с Алгола 68 в еѐ коды (Н.Н. Вояковская, Б.А. Федотов), получив возможность удобной работы в 16-разрядной архитектуре [7]. При замедлении в 4-5 раз мы в 2-3 раза выигрывали в длине объектного кода (за счѐт более высокого уровня системы команд), что тогда было очень важно. Чаще всего, первые персональные ЭВМ имели только 64 кб оперативной памяти, но микропроцессоры уже были довольно быстрыми.

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

               Вначале мы решили сделать специализированный HLL-компьютер. В это время мы уже работали с ЛНПО «Красная Заря», хорошо знали УК1010, СУВК СС, СУВК СМ, «Нева» и другие СЭВМ, ориентированные на телекоммуникационные задачи. Но из идеи специализированного для телекоммуникационных задач HLL-компьютера ничего не вышло. Для установления соединения нужны логические команды, работа с битовыми шкалами, арифметика целых чисел. Для техобслуживания нужна работа со строками, файлы, диалог с оператором, сетевые возможности и т.д. Таким образом, нам нужна именно универсальная ЭВМ, несмотря на то, что она применяется в достаточно узкой предметной области.

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

               Решение этой задачи было подсказано нашим опытом разработки трансляторов. Сначала мы заметили, что существенную часть любой ЭВМ составляют схемы контроля, более того, мы видели ситуации, когда ЭВМ не работала именно из-за ошибок в схеме контроля. Отключаешь схему контроля –и всѐ в порядке! Потом мы заметили, что многие проверки, выполняемые аппаратурой, повторяют аналогичные проверки, которые перед этим делал транслятор с АЯВУ. Поскольку мы разрабатывали и архитектуру ЭВМ, и еѐ системное ПО, мы решили, что подобная избыточность нам не нужна. Мы решили создать ЭВМ, для которой в принципе нельзя составлять программы на ассемблере, тем более, в кодах. Наша технологическая цепочка всегда включает трансляцию с АЯВУ, поэтому то, что проверил транслятор, аппаратура должна принимать "на веру". Зачем нужна проверка на неправильный код операции, неправильный номер регистра или некорректную адресацию, если транслятор такого не генерирует?

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

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

                Оказалось, что гарантировать корректную работу аппаратуры мы можем только для статических АЯВУ с полным контролем типов в период компиляции таких, как Алгол 68, Паскаль, Модула 2, Ада, но не таких, как С и PL/I. На этих принципах нам удалось создать компактную ЭВМ, мы дали ей имя "Самсон" [8], но не в честь сильного и легковерного библейского героя, а в честь самого большого фонтана у нас в Петродворце. Мы получили 3 авторских свидетельства (общая организация, совмещение регистров со стеком, организация виртуальной памяти), решили несколько интересных научных задач,привлекли в лабораторию много хороших студентов. Прежде чем был спаян хоть один провод, мы долго экспериментировали на моделях, отражающих потактовую структуру ЭВМ. Многие команды были включены в состав архитектуры именно в результате моделирования.

                Реализацией потактного симулятора занималась моя дочь Карина Терехова –тогда студентка младших курсов мат-меха. Мы с ней прогоняли сотни тестов, исследуя статическую и динамическую статистику использования разных команд и определяя, сколько тактов занимает исполнение того или иного теста. После каждого прогона теста мы брали только верхние по частоте 20-25 команд.Штук 5 команд исполнялись миллионы раз, следующие по частоте 10 команд –сотни тысяч раз, еще десяток –десятки тысяч раз, а остальные –сотни или тысячи раз, что для нас было неинтересно.

               Верхнюю строку всегда занимала команда«читать из памяти в стек целых» (40%). Нам удалось сделать однобайтовую команду, которая читала на стек одну из первых 15 переменных процедуры. Оказалось, что практически всегда только эта команда и используется, поскольку редко встречаются процедуры с большим числом локальных переменных.

                Каждый год на курсе «Архитектура ЭВМ» я рассказывал студентам, как, сидя на колхозном поле, обрубая хвостики морковки, я уговорил Колю Фоминых подумать, как сделать более эффективную реализацию этой команды. Коля полдня отнекивался, а потом все-таки придумал, как вместе 4 тактов сделать 3. Только за счет этого мы повысили производительность «Самсона» на 10%!

                Команда «условный переход по ложному условию» занимала 10% всех исполняемых команд(понятно почему –if,while), а команда «=» –8%. Мы их склеили(получив команду «переход по равно»)и выиграли 1 байт длины кода и 2 такта исполнения. Таких примеров можно привести множество.Само собой разумеется, из целей ортогональности и облегчения трансляции мы ввели команды «переход»по всем шести типам сравнений, хотя остальные команды использовались не так часто.

               Мы объездили несколько заводов в СССР с предложением наладить выпуск нашей машины. Но везде натолкнулись на отказ по той причине, что у нас не было западного прототипа.Такие тогда были времена. Нас выручил завод "Оргтехника" в г. Пловдиве (Болгария), который был побратимом Ленинграда. Все работы были оформлены как подарок к 70-летию советской власти, успешная демонстрация работы новой ЭВМ членам Политбюро БКП и нашим партийным начальникам состоялась 5 ноября 1987 года в 14 часов. В 12 часов "Самсон" еще не работал, мы не спали двое суток, под "горячую руку" попал даже наш ректор В.Б.Алесковский, о чем он со смехом напомнил мне через много лет.

               Болгары выпустили 100 экземпляров "Самсона", только после этого нам удалось убедить нашего основного заказчика в СССР–Управление правительственной связи КГБ. Для этого пришлось дополнительно разработать троированную архитектуру с очень высокой надѐжностью. Но система команд была точно такая же, поэтому болгарский "Самсон" использовался как инструментальная ЭВМ.

                Собственно, идея троированного компьютера (три процессора, три памяти, три входных мажоритара и три выходных) принадлежит не нам. Нам была известна троированная ЭВМ «Микрон», созданная в НИИАА под руководством академика В.С.Семенихина. Мы использовали такую же структурную схему, но вся реализация была своя.

               Очень важной идеей, которую мы реализовали в "Самсоне", было динамическое микропрограммирование. Н.Ф.Фоминых предложил удобную технологию микропрограммирования на Алголе 68 [9], которая в десятки раз упростила эту сложную задачу. Для стандартной системы команд "Самсона" мы занимали не более двух третей микропамяти, оставшуюся треть пользователи занимали для команд, придуманных специально для их приложений. Во многих случаях это позволяло ускорить критичные по времени фрагменты программы в 10-20 раз.

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

                Первой реализацией троированного управляющего вычислительного комплекса (УВК) «Самсон» была центральная ЭВМ АМТС «Фобос-К» Управления правительственной связи КГБ[10]. К сожалению, эта АМТС по причинам, весьма далеким от науки и техники, в серию не пошла. Тогда, воспользовавшись связями в Оборонном отделе Обкома КПСС, я договорился с ЛНПО «Импульс» о выпуске этого УВК. Сотрудники «Импульса» (особо надо упомянуть В.П.Самецкого и В.М.Зуева) переработали конструктив и отдельные элементы «Самсона» под свои требования, мы доработали инструментальные средства разработки. В 1992 году министр обороны России Грачев подписал приказ о принятии УВК «Самсон» на вооружение РВСН. Долгие годы это все было большим секретом, но в 1999 году РВСН праздновали свое 40-летие, к этому торжественному моменту была выпущена красочная толстая брошюра на мелованной бумаге. Первые 14 страниц посвящены УВК «Самсон», причем на 10-ой странице есть фраза «Архитектура и ОС УВК «Самсон» разработаны при помощи ГУП «Терком» и ЛГУ». Сначала эта фраза меня покоробила, но затем я осознал, что брошюра не содержит грифа, так что секрета больше нет. Теперь в курсе «Архитектура ЭВМ» я рассказываю студентам про HLL-компьютеры на примере УВК «Самсон». Я не думаю, что кто-то из моих выпускников будет на нем программировать, здесь главный интерес –как и почему всѐ это делалось. Часто перед рассказом какого-то раздела я спрашиваю у студентов, как бы они решили какую-то задачу построения архитектуры и иногда даже получаю ответы.

               Сейчас по заказу ФГУП «НИИ автоматики» (г. Москва) мы разрабатываем новый отказоустойчивый вычислительный комплекс (уже прошли испытания макета).

                Насколько мы знаем, "Самсон", принятый на вооружение в 1992 году, до сих порактивно используется во многих важных системах.

  Литература

1.Алгол 68. Методы реализации. Под ред. Г.С. Цейтина. –Л.: Изд-во Ленинградского университета, 1976г., 224с.

2.С.Н. Баранов, А.Н.Терехов, Г.С. Цейтин «Инструкции к программе DICO»,Методические материалы по программному обеспечению ЭВМ. Серия 4. Выпуск 5. Изд.ЛГУ, 1974г.

3.Н.Ф.Фоминых"Интерпретатор автокода МВК "Эльбрус" для ЕС ЭВМ",диссертация на соискание ученой степени кандидата физико-математических наук, Ленинград, 1987 г.

4. Гиндыш И.Б., Попов А.П., Рухлин А.П., Терехов А.Н., Фоминых Н.Ф., Швецова Г.А. "Интерпретатор АК ЛГУ для ЕС ЭВМ", изд.ЛГУ, 1981 г.

5.Дейкало Г.Ф., Новиков Б.А., Рухлин А.П., Терехов А.Н. "Новые средства программирования для ЕС ЭВМ. Транслятор с языка Алгол 68 и диалоговая система JEC", "Финансы и статистика", М., 1984г.

6.Попов А. П. "Методы реализации языка Ада", диссертация на соискание ученой степени кандидата физико-математических наук, Ленинград, 1987 г.

7.Матиясевич Ю.В., Терехов А.Н., Федотов Б.А."Унификация программного обеспечения микроЭВМ на базе виртуальной машины","Автоматика и телемеханика", N5, М., 1990 г.

8.Евстюнин М.В., Кожокарь С.К., Терехов А.Н., Уфнаровский В.А. "Как Паскаль и Оберон попадают на "Самсон",Монография по технике программирования. Кишинев, "Штиинца", 1992 г.

9.Н.Ф.Фоминых, Использование стандартного расширяемого алгоритмического языка в микропрограммировании. В сб.: Диалоговые микрокомпьютерные системы. М., МГУ, 1986 г.

10.С.А.Валдаев «Связь, которая не подведет», М., Славянский диалог, 2001 г

Как я общался с А.П.Ершовым в формальной и неформальной обстановке.

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

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

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

               Приведу пример, как А.П.Ершов учил меня избегать шумных скандалов в лаборатории:

              - Вы когда-нибудь видели, Андрей, чтобы я с кем-нибудь ругался в голос?

              - Нет, не помню.

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

                Конкретно эта идея пару раз спасла нашу лабораторию от развала в чрезвычайно острых ситуациях.

                 В 1982 году по инициативе Ленинградского обкома КПСС несколько крупных предприятий региона в содружестве с Ленинградским университетом решили развернуть широкомасштабные работы по технологии программирования для встроенных систем. Для обеспечения поддержки и финансирования проекта необходимо было заручиться поддержкой какого-либо авторитета в этой области, поэтому небольшая делегация была командирована в Новосибирск к А.П.Ершову, причем предварительно «прошел» (как тогда выражались) звонок из ЦК КПСС. Зная А.П.Ершова лично, я сильно сомневался в успехе нашей поездки. Само понятие «технология программирования» к тому времени сильно отдавало лозунговостью, а конкретные задачи и установки, переданные в Ленинградский университет, вообще были приняты «в штыки» большинством специалистов (особенно, молодых).

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

       1989 г.                                                                                                                       А.Н.Терехов

                                                    Руководитель лаб.системного программирования НИИММ ЛГУ                           

ЗАКЛЮЧЕНИЕ

О работах ленинградского научно-производственного объединения «Красная заря» Минпромсвязи СССР по организации и технологии промышленного производства программного продукта.

ВВЕДЕНИЕ

В начале XI-й пятилетки ЛНПО «Красная заря» начало работу по созданию отраслевой технологии промышленного производства программного продукта. Для формулирования основных принципов выполнения этой работы в ноябре 1982 г. было проведено техническое совещание специалистов отраслевой, академической и вузовской науки, представленных сотрудниками «Красной зари», вычислительного центра СО АН СССР и Ленинградского университета.

          В протоколе технического совещания эти отправные принципы были выражены в следующих положениях:

              – использования базового языка программирования высокого уровня;

              – разработка сквозной технологии промышленного производства, охватывающей весь его жизненный цикл;

              – создание унифицированной вычислительной среды для производства программного продукта и функционирования управляющих вычислительных комплексов, входящих в системы связи и управления;

               – формирование системы подготовки и переподготовки кадров для производства программного продукта.

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

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

ОРГАНИЗАЦИЯ РАБОТ

              Прежде всего следует отметить своевременность внимания руководства отрасли к проблемам технологии программирования. Я наблюдаю за работами корпорации АТТ по компьютеризации связи и технологии программирования более 15 лет и обнаруживаю, что в течение всего этого времени научно-конструкторские подразделения АТТ ведут соответствующие исследования и разработки в полном объеме и на всех уровнях –от фундаментальных работ по теории программирования до переподготовки высшего руководства корпорации.

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

              Принципиально важным моментом стало создание в отрасли специализированной организации (НИИ «Звезда»), ориентированной на разработку программного продукта и, в особенности, на создание, освоение и развитие технологии промышленного производства программного продукта. Я сравниваю создание НИИ «Звезда» с организацией 13 лет назад новосибирского филиала ИТМиВТ, сыгравшего в прошедшей пятилетке решающую роль в программном обеспечении МВК «Эльбрус». Практика показывает, что всюду, где технологии программирования низводятся до уровня вспомогательного подразделения, обслуживающего разовый тематический проект, программное обеспечение утрачивает свою главную функцию –быть своеобразным клеящим веществом, объединяющим компоненты системы и гарантирующим как её устойчивость, так и развиваемость. В качестве примера программистской организации, удачно сочетающей и тематическую и технологическую работы, мог бы назвать Отделение федеральных разработок корпорации ИБМ, где технологи программирования, составляя меньшинство, тем не менее формируют организационный каркас Отделения, пронизывающий каждый конкретный тематический проект и позволяющий разумно сочетать единство воли руководителя проекта со строгой технологической дисциплиной.

              Очень ценной и полезной для дела является органическая связь НИИ «Звезда» с Ленинградским университетом. Здесь важно влияние в обе стороны: реализация высокой наукоемкости производства программ, обеспечение заблаговременной и сквозной подготовки специалистов, наличие восприимчивой и быстрой на отдачу базы для проведения поисковых разработок, которые было бы трудно или рискованно разворачивать в производственной обстановке отраслевого предприятия.

ВЫБОР БАЗОВОЙ ТЕХНОЛОГИИ

               Я считаю абсолютно правильным и перспективным решением основывать технологию программирования на мощных кросс-системах, использующих инструментальный язык программирования высокого уровня –конкретно, Алгол-68. Эта правильность подтверждается следующими более конкретными причинами:

             – наличие развитой системы программирования с Алгола-68;

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

             – возможность использования Алгола-68 как языка для алгоритмической спецификации программ;

             – существенное ускорение обратной связи при проектировании программ благодаря применению метода исполняемых прототипов прототипов;

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

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

              Следует отметить, что внутренняя логика развития технологии программирования на базе Алгола-68 привела специалистов отрасли к проблеме определить свое отношение к исторически обусловленным технологическим вариантом в лице R-технологии и системы разработки программного обеспечения РУЗА , использованным в ранее начатых разработках. Не желая сказать ничего плохого об этих технологиях в естественных пределах их применимости, подтверждаю правильность переключения с этих технологий на Алгол-68 по следующим причинам.

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

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

               Что касается системы РУЗА, то она уступает технологии Алгола-68 по своим внутренним свойствам как система ассемблерного типа.

ОРГАНИЗАЦИОННАЯ ДИСЦИПЛИНА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

               Следует подчеркнуть, что работа по созданию технологии промышленного производства программного продукта велась в «Красной заре» с двух встречных направлений: снизу –в виде конкретных кросс-систем на базе Алгола-68 и сопутствующих подсистем и сверху –в виде так называемого гибкого автоматизированного производства программного обеспечения систем связи, представляющего собой совокупность нормативных документов и организационных процедур в сочетании с рядом средств документационной поддержки проектов.

              Последняя работа представляет собой своего рода программу-максимум, охватывающую все стадии и всех участников разработки программного продукта, и разрабатывалась пока, главным образом, на организационно-проектном уровне.Ее основные показатели адекватно отражены в актах о приемке работы на стадии НИР и по завершении создания опытного участка. Я подтверждаю перспективность и тщательность этой разработки и её соответствие мировым тенденциям. Не исключено, однако, что потребуется дальнейшая работа по стыковке ГАП ПО систем связи с конкретными тематическими проектами и, в связи с этим, по упрощению и повышению практичности форм взаимодействия в проекте и отдельных технологических процедур.

АПРОБАЦИЯ РАЗРАБОТАННОЙ ТЕХНОЛОГИИ

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

              – сложившиеся проекты с выбранной технологией,

              – начавшиеся проекты с невыбранной технологией,

              – будущие проекты.

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

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

ВЫВОДЫ И РЕКОМЕНДАЦИИ

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

            II.   На Алгол-68 можно спокойно ориентироваться по крайней мере до конца 80-ых годов. АДА, являясь более современным языком, еще не имеет доступной и развитой среды. Язык Чилл по своим возможностям близок к Алголу-68и пока еще является предметом комитетской работы, рассматривающей проблемы его стандартизации и реализации, однако нет достоверной информации о больших капитальных вложениях в разработку технологии на его основе.

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

           IV.   Возникает естественный вопрос: должна ли отрасль стремиться к единой технологии разработки программного продукта, синхронно применяемой во всех тематических проектах? Хотелось бы предостеречь от волюнтаристского подхода к решению этой проблемы, подтверждая, однако, критическую важность выбора правильной технологии программирования при разработке современных глобальных компьютерных систем, каковыми являются системы связи. Из этого вытекают такие следствия:

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

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

           – Конкретно, МВП-технология еще должна проявить себя на деле в условиях полномасштабного применения. Однако, уже сейчас видно ее важное преимущество по сравнению с ассемблерными системами или даже технологиями на базе языка Си и обстановок типа Юникс. Это преимущество состоит в том, что языковые свойства Алгола-68 и близких ему языков позволяют перенести центр тяжести работы на «функционалистов», т.е. не столько на профессиональных системных программистов, слабо ориентирующихся в тематике, сколько на квалифицированных тематиков, обладающих необходимым минимум знаний по алгоритмизации и программированию. Предлагаемый НИИ «Звезда» метод организации «динамических коллективов» позволяет гармонично объединить специалистов разных квалификаций в интересах проекта.22 февраля 1986 г.

Академик                                                                                                                       А.П.Ершов

 История одной идеи                 

1. Предыстория

              Я окончил мат-мех ЛГУ в 1971 году, причем первым защитил диплом в первом выпуске новой кафедры математического обеспечения ЭВМ. Моим научным руководителем был доктор физ-мат наук Григорий Самуилович Цейтин, под руководством которого большая группа студентов и сотрудников ВЦ ЛГУ занимались реализацией языка Алгол 68 для ЕС ЭВМ. Темой моей дипломной работы был поиск цепочки приведений (преобразований типов) в Алголе 68. В 1974 году было опубликовано «Пересмотренное сообщение об Алголе 68», в котором язык был существенно упрощен, но в первом варианте языка приведения и эквивалентность видов (в том числе рекурсивных) были очень трудными задачами.

              Г.С.Цейтин предложил мне поступить в аспирантуру, честно предупредив, что у него уже было довольно много аспирантов, но ни один пока не защитился. Мы стали обсуждать возможную тему диссертационной работы. Мне уже тогда казалось, что тема анализа алгоритмических языков (как видонезависимого, так и видозависимого) практически исчерпана, поэтому я попросил предложить мне какую-нибудь тему по синтезу(генерации) кода. Здесь у нас было новое, прорывное решение. Г.С.Цейтин существенно улучшил идею Бранкара и Леви[1], которые предлагали во время синтеза анализировать стек объемлющих инструкций, чтобы понять какой именно вариант генерации кода будет оптимальным в данном конкретном случае. Такое решение приводило к перебору огромного числа вариантов. Вместо этого Г.С. Цейтин предложил элегантную идею запросов и ответов  [2], существенно упростившую схему синтеза.

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

              Таким образом, возникает задача предсказания будущего контекста. И вот тут Г.С.Цейтин вспомнил, что лет 15 назад он уже продумывал решение этой задачи, правда, в совершенно другой области –в задаче перевода с одного естественного языка на другой. Г.С.Цейтин руководил лабораторией математической лингвистики, а всё, что он делал с нами в ВЦ ЛГУ было для него, так сказать, хобби, правда, высокопрофессиональным (как и все,что он делал в других областях). В середине 50-х годов он пытался реализовать перевод с русского языка на английский. Разумеется, на ЭВМ того времени это были только эксперименты, но многие задачи были сформулированы уже тогда. Рассмотрим пример. «Иван разбил чашку», «Вася разбил сад». В первом случае слово «разбил» имеет отрицательный характер, во втором –положительный, с совершенно другим смыслом. Уже тогда Г.С.Цейтин понял, что смысл слов надо кодировать не простыми значениями, а «условными», представленными в виде дерева вариантов. Слабость тогдашней техники (особенно малые размеры памяти) не позволили ему даже провести эксперименты. Спустя 15 лет Г.С.Цейтин предложил мне этим заняться.

2. Постановка задачи

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

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

               • во втором просмотре исключаем из текста ненужные выгрузки.

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

a) две разные альтернативы могут оказаться "ортогональными" друг другу, т.е. изменения в порождаемой программе, обусловленные выбором решения по одной из альтернатив, не будут зависеть отрешения по другой альтернативе;

b) каждое принимаемое решение касается программирования определенной конструкции и, вообще говоря, не влияет на программу после окончания этой конструкции.

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

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

               Подробное обсуждение задачи приведено в [*3].

3. Условные значения

              Некоторые операторы в программе могут находиться внутри условных предложений и выполняться или не выполняться в зависимости от значений определенных предсказателей. Среди таких операторов могут оказаться и присваивания, и, таким образом, на выходе из условного предложения, управляемого предсказателем, окажется, что значение некоторой переменной зависит от этого предсказателя. Далее эта зависимость может распространяться на результаты операций с таким значением, на условные предложения, управляемые результатом такой операции и т. д. Поэтому считается, что любое значение, над которым производится действие, может быть условным, например, иметь вид: if A then x elif B then y else z fi.

              Однако, учет этих условностей не должен усложнять написание макроопределений порождения рабочей программы, и для автора макроопределений эти значения должны выглядеть как простые. Система, реализующая описываемый способ синтеза (далее будем говорить просто система), использует специальный способ представления этих значений в виде двоичного дерева; каждый узел соответствует некоторому предсказателю, а две дуги, выходящие из этого узла, соответствуют значениям предсказателя true и false. В висячих вершинах этого дерева находятся конкретные значения. Операции над такими деревьями (арифметические операции, присваивания, сравнения и т.п.) выполняются при помощи специальных процедур.

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

              Кроме того, значение текущего условия изменяется, если обнаруживается, что при некотором сочетании значений предсказателей программирование не может продолжаться (например, из-за отсутствия свободных регистров); в этих случаях к текущему условию конъюнктивно присоединяется условие продолжимости генерации.

               Значение текущего условия влияет на исполнение присваиваний и генерацию рабочей программы. Если при текущем условии B исполняется присваивание x:=y, то фактически x присваивается значение if B then y else x fi (технически эта операция несколько сложнее, поскольку B, x, y могут быть условными). Если же при текущем условии B генерируется текст рабочей программы, то он должен быть снабжен пометкой, что в окончательную программу он войдет, лишь если значение B в конечном счете окажется true. Фактически такие пометки в рабочей программе достаточно ставить лишь в тех точках, где текущее условие изменяется.

               Рассмотрим условное предложение if A then S fi. Пусть перед входом в это предложение значением текущего условия было B. Тогда S исполняется при значении текущего условия B&A. Условное предложение  if  A then  S1  else  S2   fi  в принципе реализуется так же, как

bool AA=A;  if AA thenS1 fi;  if not AA then S2 fi.

              Рассмотрим цикл   while  A  do  S  od. Предположим, что известно целое число N, ограничивающее сверху число повторений цикла. Тогда для данного цикла можно определить эквивалентное выражение S_N следующим образом:

              в качестве S₀ берем skip;

              в качестве S_k+1 берем if A then S; S_k fi.

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

4. Представление условных значений

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

mode узелX= struct (int предсказатель, значениеX да, нет); mode  значениеX= union (X, ref узелX);

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

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

              Система обрабатывает все идентификаторы простых переменных, а также элементы массивов как значения видов значениеX. Такая замена видов происходит автоматически.

              Основным способом выполнения различных действий над значениями, представленными в виде двоичных деревьев, является копирование двоичного дерева в свободных ячейках памяти с выполнением соответствующего действия на каждой висячей вершине этого дерева. В результате такого действия вместо висячей вершины может быть, в частности, вставлена копия другого дерева, полученная аналогичным процессом. Например, для того, чтобы получить сумму двух значений, заданных в виде двоичных деревьев, мы можем копировать дерево первого слагаемого, выполняя в каждой его висячей вершине следующее действие: запоминаем число, стоящее в этой вершине, затем копируем второе слагаемое с увеличением числа в каждой его висячей вершине на запомненное число из первого слагаемого, получившееся дерево вставляем на место этого числа в копию первого слагаемого. Фактически такое копирование не обязательно будет копированием полного дерева. Именно, при копировании первого дерева мы запоминаем в стеке путь от его корня к текущей вершине и, таким образом, мы имеем список значений всех предсказателей, по которым производилось ветвление на этом пути. Когда в висячей вершине первого дерева мы начнем копирование второго дерева, то оно будет выполняться уже при определенных значениях предсказателей из первого дерева; поэтому, встречая во втором дереве ветвление по предсказателю, значение которого уже записано в стеке, мы не копируем узел с таким ветвлением, а просто сразу идем по нужной ветви и рассматриваем встретившуюся там вершину вместо данного узла. Такое неполное копирование может применяться и к первому копируемому дереву, если текущее условие конъюнктивно содержит некоторые предсказатели или их отрицания. Список таких предсказателей выделяется из текущего условия посредством специальной операции и добавляется к началу стека, используемого для копирования.

             Рассмотрим как используется описанная техника при действиях над условными значениями.

             Для присваивания переменной значения сначала копируется дерево текущего условия, после чего висячие вершины со значением true заменяется копией дерева источника, а висячие вершины со значением false–копией дерева значения, именуемого получателем. Полученное дерево объявляется новым значением переменной. Таким образом, при тех значениях предсказателей, при которых текущее условие есть false, переменная своего значения не изменяет.

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

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

            a) дерево эквивалентно константе;

            b) дерево может быть преобразовано к виду:

             if A then x elif B then x elif...elif произвольное дерево fi

            Здесь x обозначает конкретное значение. A, B,... обозначают предсказатели или их отрицания.

             В частности, если в таком виде представлено значение текущего условия, причем x есть false, то для генерируемого в данный момент варианта значения определенных предсказателей зафиксированы таким образом, что A,B,... все имеют значение false. Это используется для упрощения копирования деревьев. Для приведения дерева к виду b) используется следующий алгоритм.

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

            если было "пусто", то A;

            если было A, то значение не изменится;

            в других случаях пишется код "*".

            После окончания обхода дерева просматривается таблица. Если найдется строка, в обоих столбцах которой записаны значения, отличные от кода "*", то результирующее значение будет либо константой (если эти два значения совпадают), либо будут состоять из одного узла, обе ветви которого–конкретные значения, взятые из этой строки таблицы.

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

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

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

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

       В заключение отметим, что этот алгоритм, конечно, не дает полной оптимизации деревьев, например,

a) не будет замечено, что дерево не зависит от некоторого предсказателя, хотя его и содержит;

b) не будут найдены эквивалентные поддеревья.

              Для того, чтобы проверить изложенные выше методы, была предпринята экспериментальная реализация на инструментальной ЭВМ «Одра 1204». Эта небольшая ЭВМ на мат-мехе ЛГУ предоставлялась в режиме индивидуального использования. В её матобеспечение входила практически полная реализация Алгола 60, а мы реализовали удобную систему для диалоговой отладки и исправления текстов[4+. Вся оперативная память, доступная для динамического распределения, составляла примерно 5000 ячеек, что, конечно, не позволяло проводить масштабные эксперименты. Тем не менее, все алгоритмы были реализованы и проверены на реальных примерах *5+. В это время ожидался массовый выпуск ЕС ЭВМ, поэтому мы решили отложить дальнейшие исследования на некоторое время.

5. Неожиданное продолжение

              В конце 1975 года диссертация была переплетена, основные результаты были опубликованы в академическом журнале  [3]. В начале 1976 года в Академгородке (г.Новосибирск) состоялась большая международная конференция, на которой я выступил с докладом о своих результатах.

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

              Одним из таких ученых, часто приезжавших в Академгородок, был Джекоб Шварц, по книге которого мы в университете учили функциональный анализ [6]. «На старости лет» Джекоб решил переквалифицироваться в программиста и создал первый в мире язык сверхвысокого уровня SETL, в котором элементарными данными были множества, деревья, списки и т.д. Одну из наиболее успешных реализаций SETL осуществили как раз в Академгородке (Давид Левин).

              Так вот, когда я закончил свой доклад, Джекоб Шварц, сидевший, как всегда, на первом ряду, спросил меня: «А как Ваш метод соотносится с языками искусственного интеллекта Planner и Conniver?». Я даже не слышал о таких языках, переспросил Г.С.Цейтина, сидевшего в зале, но и он ничего об этом не знал. Интернета тогда не было, а «железный занавес» -был. Вечером я напросился к Джекобу в компанию на ужин в единственной тогда гостинице «Золотая долина». Обслуживание там было типично советским, поэтому за 2 часа Джекоб рассказал мне об этом новом для нас направлении. Я очень расстроился, мне показалось, что моя диссертация «накрылась медным тазом», по крайней мере, предсказатели, перебор вариантов, поиск оптимального решения в AI-языках (ArtificialIntelligence) присутствовали. Позже Джекоб прислал мне бандероль с подборкой статей на эту тему[7-10], ксероксов тогда не было, поэтому эти статьи были зачитаны до дыр сотрудниками мат-меха ЛГУ.

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

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

6. Чем можно заменить механизм возвратов в задачах поиска решения

               Впервые механизм возвратов был четко сформулирован, по-видимому, в языке PLANNER

[8]. Мы рассмотрим его, пользуясь "алголоподобными" методами описания.

               Пусть обходится дерево решений. Есть средства для фиксации точек ветвления

If   ok  then  вариант1 else вариант 2 fi

и есть оператор, указывающий на невозможность продолжения варианта (fail). Система, интерпретирующая текст на таком языке, встретив оператор ветвления, запоминает состояние памяти и запускает первый вариант. Если встретится fail, то система восстанавливает содержимое памяти в момент последней точки ветвления и запускает альтернативный вариант; если в данной точке ветвления вариантов больше нет, то рассматривается предыдущая точка ветвления.

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

[8] int a;

for i to 8 do a[i]:=0 od;

proc p= (int i) void:

co устанавливает ферзя в i столбце на такую позицию, в которой он не бьет 1, ... , i-1 ферзей (последняя занятая позиция в i столбце фиксируется в a[i]); если такой позиции нет, то a[i]:=0 и выдается fail  co

for i to 8 do

m: p(i);

if  ok  then

if i=8 then print (a) else go to m fi od

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

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

if ok then A1 else A2 fi;

if ok then B1 else B2 fi;

if ok then C1 else C2 fi;

здесь операторы B1 и B2 выполняются по 2 раза, операторы C1 и C2 – по 4 раза и т.д.) заставили признать, что PLANNER поощряет "плохую практику программирования" [9].

            Поэтому PLANNER так и не был реализован в полном объеме. G.J.Sussman (один из авторов первой реализации MICRO-PLANNER[10]) сделал попытку преодолеть указанные трудности. Он предложил язык CONNIVER [9], в котором многие действия, выполняемые автоматически в языке PLANNER, должен указывать программист. В частности, автор программы определяет, значения каких переменных нужно запоминать в точках ветвления, задает явно контексты для выполнения операторов и т.д. Это позволило резко улучшить эффективность работы, но практически явилось шагом назад; как и в традиционных языках программирования, программист должен сам заботиться о многих технических деталях, что затемняет сущность решения задачи.

            Нужно заметить, что G.J.Sussman сделал несколько интересных предложений и не связанных явно с повышением эффективности механизма возвратов.

            Оператор fail был заменен на процедуру, вычисляющую текущую стоимость варианта. Если написать work(S), то текущая стоимость увеличится на S; очевидно, что work(∞) эквивалентно fail.

            Левосторонний обход дерева решений был заменен "параллельным" сравнением вариантов (если текущая стоимость варианта превысила некоторый порог, то вариант приостанавливается и запускается следующий вариант, причем порог постепенно растет).

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

            1. Язык искусственного интеллекта строится на основе описанной в данной работе системы синтеза рабочей программы.

            2. Точки ветвления можно задавать, например, следующим образом:

if ok then A1 else A2 fi.

            3. Определяется явная функция стоимости варианта (аналогично work в CONNIVER) и точки, в которых должно происходить сравнение вариантов.

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

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

7. Долгожданное продолжение

              Я успешно защитил кандидатскую диссертация, меня сразу же назначили исполняющим обязанности заведующего лабораторией системного программирования ВЦ ЛГУ. Собственно, эти обязанности я уже исполнял несколько лет, но в те времена завлабом в Университете мог быть только доктор наук, поэтому мне, даже не кандидату наук, шансов занять эту позицию не было никаких. Таким образом, моей защите начальство обрадовалось больше меня и сразу на меня свалилось огромное количество административных работ.Ранее директору ВЦ ЛГУ ШаумануА.М. (кстати, одному из самых любимых мною начальников) видимо было просто неудобно возлагать на меня обязанности, не давая никаких прав. В эти же годы мы были по горло заняты завершением работ и сдачей заказчику (НИЦЭВТ) нашего главного детища -транслятора с языка Алгол 68 для ЕС ЭВМ. Всестаршие товарищи, начинавшие проект, когда мы были еще студентами, не выдержали еженедельных командировок в Москву, где мы отлаживали транслятор на IBM360 исключительно в ночное время, так что завершал этот проект я уже руководителем.

             В декабре 1980 года ректор ЛГУ В.Б.Алесковский поручил мне сотрудничество с Оборонным отделом Обкома КПСС, наши военные испытывали большие трудности с внедрением цифровой вычислительной техники и обратились за помощью в Университет. Появился новый круг обязанностей (и возможностей), новые интересные задачи, время летело. В эпоху перестройки государство перестало платить по оборонным заказам, пришлось срочно искать западных заказчиков. С этой абсолютно новой задачей мы также успешно справились, но практически потеряли возможность заниматься фундаментальными исследованиями в той же мере, как это было в счастливых для нас семидесятых годах.

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

             Один раз мое сердце дрогнуло. Это было в середине 90-ых годов. По заказу итальянской компании ITALTEL мы создавали технологию проектирования гибких кристаллов (FPGA) и столкнулись с задачей минимизации булевских формул. Ещё когда я был студентом мат-меха, нас учили, что это пример сложной задачи, для которой возможны лишь решения, связанные с полным перебором, т.е. имеющие экспоненциальную сложность. На военной кафедре на лекциях по электронике нас учили, как получить почти оптимальную форму (диаграммы Вейча, метод Квайна-МакКласки), но итальянцы показали нам работы американских учёных из Беркли по BDD(двоичным диаграммам решений), которые эту задачу решают очень быстро. Фокуса тут никакого нет, теория, как всегда, права, просто для формул ограниченной длины (скажем, содержащих до 1 млн. переменных, что с избытком покрывает практические потребности), применяя хэширование с длинной сверткой и большими таблицами, можно найти поддерево в дереве за 1 сравнение. Я не буду в этой обзорной статье углубляться в математику этого вопроса [11], скажу только, что все довольно просто. Я сильно обозлился на себя и на своих сотрудников, что мы не только не придумали этого сами, но и прозевали столь интересный результат.

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

             Я несколько раз предлагал эту тему своим аспирантам, но интереса она не вызвала, а мне неудобно было настаивать, все-таки, речь шла о моей кандидатской, защищенной много лет назад. Помог случай. Один из лучших теоретиков среди моих учеников Дмитрий Булычев поручил своему дипломнику Д.Иванову разработать библиотеку операций над BDD на языке OCaml (на этом новом очень удобном языке мы собираем большую библиотеку средств анализа программ, операций на графах и т.д.). Дипломник со своей задачей справился, но не предоставил ни одного содержательного примера (к сожалению, стремление минимизировать свои усилия–типичная черта современных молодых специалистов). Мне, как заведующему кафедрой, пришлось разбираться в этом споре между научным руководителем и студентом. Разумеется, я всецело был на стороне научного руководителя, но и «гробить» хорошего студента не хотелось.

             Я предложил Д.Иванову за оставшиеся до защиты 2 недели реализовать несколько основных операций над условными значениями, базируясь на его библиотеке BDD. Результат превзошел все ожидания, Д.Иванов получил «красный» диплом, а я пригласил его к себе в аспирантуру. Не все шло гладко, например, я потратил много времени на объяснение, что висячими вершинами BDD могут быть не только логические значения, но и произвольные значения, например, целые числа. Для меня это было совершенно естественно, но действительно противоречило каноническим определениям. Долго мы не могли подобрать хорошую модельную задачу, которая должна быть достаточно сложной, но, в то же время, иметь локальные варианты, не полностью зависящие друг от друга. Хорошую задачу предложил М.Бульонков. Это задача составления расписания для школы или другого учебного заведения. Есть набор предметов, учителей, которые их могут преподавать, ограниченный набор аудиторий и множество ограничений-пожеланий учителей, например, чтобы не было «дырок» между занятиями, чтобы были свободные дни и т.д.

              В качестве модельной мы использовали более простую подзадачу –задачу о назначениях:

              Есть N потребителей и K ресурсов, каждый потребитель может использовать только один ресурс из специфичного для этого потребителя набора ресурсов. Если потребитель использует ресурс, то другой потребитель его использовать уже не может. Требуется назначить каждому потребителю свой ресурс.

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

               Приведем результаты сравнения этих методов в зависимости от количества ресурсов.

               На наш взгляд, результаты говорят сами за себя.

            Чтобы окончательно убедиться в преимуществах нашего подхода, мы провели эксперименты с более сложной переборной задачей. На шахматной доске расставлена позиция. Требуется поставить мат за заданное количество ходов. Оказалось, что поиск-в-ширину и здесь выигрывает, причем увеличение числа ходов на 1 увеличивает коэффициент выигрыша в 2-3 раза. Увеличение числа фигур на доске также существенно повышает выигрыш нашего метода.

8. Заключение

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

           1.Идеи (как и рукописи) не горят.

            2.Программисты-практики не должны относиться к теории как к абсолюту. Большинство практических задач имеют такие особенности и ограничения, которые позволяют найти более эффективные решения. Студентов кафедры системного программирования СПбГУ я учу, что главным для нас должен быть лозунг adhoc–для данного конкретного случая.

Список литературы

 1.Branquart P., Cardinael J. P., Lewi J. "An optimised translation process and application to ALGOL 68. Part 1:   General Principles" // MBLE Lab. de Rech., Report R209, Bruxelles, September 1972

 2."Алгол 68. Методы реализации" Соавторы: Балуев А.Н., Братчиков И.Л., Гиндыш И.Б., КрупкоН.А.,   Терехов А.Н., Цейтин Г.С.(всего 12 чел.), изд.ЛГУ, 1976г.

 3.Терехов А.Н., Цейтин Г.С. "Средства эффективного синтеза объектной программы" "Программирование", N6, 1975 г.

 4.С.Н. Баранов, А.Н.Терехов, Г.С. Цейтин «Инструкции к программе DICO»,Методические материалы по программному обеспечению ЭВМ. Серия 4, Выпуск 5,изд.ЛГУ, 1974г.

 5.Терехов А.Н. "Распределение регистров в рабочей программе","Программирование", N1, 1977 г.

 6.Данфорд Н., Шварц Дж.Т., «Линейные операторы (том 1) Общая теория.», Изд-во: М.:Наука, 1974 г.

 7.Bobrow D. G., Raphael B. "New programming languages for AI research" //Xerox Palo Alto Research Center, August 1973

 8.Hewitt C. "Description and theoretical analysis (using schemata) of Planner: A language for proving   theorems and manipulating models in a robot" // AI MemoNo. 251, MIT Project MAC, April 1972

 9.McDermot J., Drew V., Sussman G. J. "The Conniver reference manual" // AIMemo No. 259, MIT Project MAC,   May 1972

 10.Sussman G. J., Winograd T. "Micro-Planner reference manual" // AI MemoNo. 203, MIT Project MAC, July   1970

 11.Randell E. Bryant. Symbolic Boolean manipulations with ordered binary decision diagrams. ACMComputer   Surveys, 24(3):293-318, September 1992.

Эволюция наших взглядов на CoDesign за последние 15 лет

             Мы познакомились с понятием CoDesign (совместное проектирование аппаратных и программных средств) в процессе работы с сотрудниками департамента R&D фирмы ITALTEL (г.Милан). Надо сказать, что это сотрудничество было многолетним и успешным, например, мы реализовали первый в Европе АТМ-коммутатор (аппаратура и ПО, а также средства управления глобальными АТМ сетями). Позже мы сосредоточили свои усилия на реализации ПО мобильных телефонов. В те годы мобильная связь только начинала развиваться и, пожалуй, основной проблемой была battery supply, т.е. эффективность использования электроэнергии, обеспечиваемой громоздкими аккумуляторами. Итальянцы сначала заказали нам разработку ПО мобильных телефонов (именно трубок, а не базовых станций или MSC) всех известных на тот момент стандартов NMT, GSMи СDMA, а потом попросили оценить,какой процент возможностей микропроцессора М6800 используется для выполнения этого ПО. Результат нас ошеломил – не более 20%! На уровне вентилей нет возможности управлять потреблением электроэнергии, вентилю не скажешь: «в этот такт помолчи и ничего не делай».

              Так возникла идея разработки микропроцессора, специальным образом оптимизированного на заданную задачу. Разработка микропроцессора –это очень сложная и дорогая задача, но и мобильные телефонные трубки выпускаются миллионами. Чуть позже обнаружились и другие массовые приложения, где выгодно использовать специализированные микропроцессоры, поэтому задача была обобщена следующим образом. Пусть имеется программа на каком-либо алгоритмическом языке высокого уровня. Заданы ограничения на время исполнения этой программы, например, каждая нить должна исполняться не более чем за 1 мс. Требуется спроектировать микропроцессор, который выполняет заданную программу с учетом временных ограничений и имеет при этом минимальное число вентилей (минимальное потребление электроэнергии, минимальная стоимость – все эти факторы практически линейно зависят друг от друга). В качестве дополнительного важного требования выдвигалась автоматическая генерация компилятора в систему команд создаваемого микропроцессора, отладчика, потактового симулятора и других инструментальных средств – ведь оптимальный микропроцессор рождался «голым».

               Мы приступили к решению этой задачи и примерно за год нащупали подход, как нам казалось, вполне перспективный. Мы предложили разработку средств, позволяющих найти в программе повторяющиеся «время пожирающие» части, точнее объекты, чтобы можно было инкапсулировать и данные, которые эти объекты обрабатывают. Затем эти объекты нужно реализовать в виде специализированных команд, расширяющих какую-то выбранную заранее архитектуру. Процесс предполагался итеративным: выбор объектов-кандидатов, расширение системы команд, генерация компилятора и симулятора, профилирование, оценка того, что получилось, если результаты не удовлетворяют архитектора, процесс повторяется, начиная с новых кандидатов. Такой подход к CoDesign был опубликован в трудах международной конференции в Берлине в 1996 г. [1].

              Однако не всё оказалось так просто. Для реализации автоматической генерации компилятора в только что полученную систему команд мы сильно рассчитывали на технику retargetable compiler generation, мы прочитали десятки статей на эту тему, выполнили целый ряд масштабных экспериментов [2], но оказалось, что трудности такого описания архитектур ЭВМ, по которому можно автоматически сгенерировать кодогенератор, слишком велики для задачи CoDesign, в которой по нашему плану архитектор мог бы менять архитектуру за минуты.

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

               Итак, задача сводится к «раскраске» дерева разбора программы маленькими поддеревьями, т.е. командами с заданными ограничениями. Как известно, задача поиска поддерева в дереве имеет экспоненциальную сложность, поэтому для реальных программ такое «лобовое» решение будет работать очень долго. Д.Булычеву удалось найти эффективный алгоритм, в котором экспоненциальная часть сведена к минимуму. Мы провели целую серию экспериментов, в которых выбирали оптимальную систему команд для известных библиотек, ориентированных на область встроенных приложений. Даже для больших программ время выбора оптимальной системы команд не превышало одной минуты, при этом сокращение длины кода по сравнению со стандартными архитектурами было существенным. Заметим, что при таком подходе задача генерации компилятора просто исчезла –объектный код получается сразу во время выбора системы команд. Были разработаны прототип генератора VHDL, т.е. аппаратной реализации выбранной архитектуры (правда, только для однотактных команд без конвейера), генераторы ассемблера, дизассемблера и потактного симулятора. В 2004 г. Д.Булычев защитил кандидатскую диссертацию[3], на основе которой в ЗАО «Ланит-Терком» был открыт инвестиционный проект по доведению этой многообещающей работы до промышленной технологии.

               Чтобы добиться максимальной эффективности, необходимо максимально распараллелить исходную программу. Эта задача давно известна и популярна, но её решение имеет теоретические пределы, кроме того, часто пользователь может предложить исполнять два фрагмента программы параллельно, даже если с формальной точки зрения это невозможно (например, он знает, что какие-то ситуации в его программе не встретятся по каким-то внешним, не отраженным в тексте программы причинам). Таким образом, входным языком системы CoDesign должен быть не стандартный С (или какой-то другой традиционный язык высокого уровня), а специально разработанный язык, который, с одной стороны, достаточно выразителен и удобен для пользователя, а, с другой стороны, дает возможность пользователю определять параллельные конструкции на любом уровне и допускать эффективную реализацию в VHDL или Verilog.

Обзор аналогичных работ

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

                В проекте ROCCC 2.0 [4]используется С-подобный язык для распараллеливания тел циклов. Параллельные версии циклов затем отображаются в FPGA для обеспечения большей производительности. Собственно, весь этот проект ориентирован на высокопроизводительные вычисления, а не на разработку аппаратуры. Например, в этом языке нет понятия цикла, поэтому невозможно описать произвольную аппаратуру.

                 Spec C [5] – расширение С для разработки аппаратуры. Взаимодействие между параллельными сущностями базируется на событиях. Семантика временных интервалов для доставки событий практически повторяет семантику VHDL. Предусмотрены операторы для описания произвольного потока управления и для явного указания параллелизма и конвейера. С другой стороны, нет явного деления на аппаратные такты(clocks), что, в свою очередь, не позволяет определить надежную доставку сообщений, приоритеты для каналов, через которые несколько сообщений могут быть посланы одновременно (т.е. в одном и том же такте).

                Handel-C [6] (построен на основе языка Occam[7], который, в свою очередь, базируется на модели взаимодействующих последовательных процессов CSP[8]) представляет из себя еще одно расширение С. Handel-C предназначен для проектирования синхронных решений с удачной семантикой каналов и надежной доставки сообщений.

                В то же время в этом языке не хватает некоторых возможностей для достижения максимальной эффективности:

                1.Сообщение не может быть принято и отправлено дальше внутри одного такта.

                2.Несколько процессов не могут получить сообщение из одного и того же канала в одном такте.

                 3.Процесс не может отказаться от приема сообщений.4.Структурная декомпозиция в Handel-C не такая удобная, как в VHDL

                 Bluespec [9,10] позволяет описывать системы в виде множества модулей, взаимодействующих через команды, которые они посылают друг другу, или через доступ к портам, из которых разрешено только чтение. Внутреннее описание модуля основывается на концепции охраняемых атомарных действий, которые оперируют с локальными данными модуля. Каждое действие предваряется предикатом, разрешающим исполнение действия в этом такте. Чтобы выполнить какие-то действия параллельно, нужно запустить специальный динамический планировщик, для которого пользователь должен задать дополнительные данные.

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

                SystemC [11] позволяет описывать аппаратуру на разных уровнях абстракции и предназначен, в основном, для моделирования на системном уровне, хотя и имеет возможности описания аппаратуры на RTL уровне. Строго говоря, SystemC – это не язык, а скорее набор идиом (образцов) для языка С++. Мы думаем, что «программирование в терминах идиом» делает невозможным многие желаемые расширения языка, например, нужный поток управления.

Краткий обзор предлагаемого нами подхода

                После нескольких лет напряженной работы над распараллеливанием и конвейеризацией программы пользователя, предназначенной для аппаратной реализации, было решено начать с другого конца. Мы определили минимальное ядро языка, в котором конвейеризация заложена с самого начала и почти не видна пользователю, для параллелизма предусмотрены наглядные средства, эффективно реализуемые в аппаратуре, а традиционные конструкции высокого уровня (циклы, процедуры, сравнение с образцами и т.д.) задаются как расширения ядра, причем каждое расширение может быть точно описано средствами ядра. Основные действия ядра –посылка и прием сообщений, нет даже понятия состояния. Чтобы в следующем такте процесс «помнил» состояние, он в конце каждого такта посылает информацию о состоянии себе на вход, а присваивание – это посылка нового значения на более приоритетный вход этого процесса. Язык, получающийся объединением ядра и расширений, получил название HaSCoL(Hardware and SoftwareCodesign Language, т.е. язык для совместной разработки аппаратных и программных средств).

                 Программа на языке HaSCoL представляет из себя множество процессов, общающихся между собой сообщениями через свои разъемы (соединители,plugs), которые бывают входными и выходными. Например:

process X =

           begin

                     in input;

                     out output (int);

             end;

                Здесь описан процесс Х, в котором есть входной разъем input без параметров и выходной разъем output с одним целым параметром. Поскольку в начале такта в разъем может прийти несколько сообщений из разных источников, нужно уметь как-то управлять их приоритетами. Для этой цели служит понятие порт, например,

in input (int, int) [A,B];

здесь входной разъем input имеет два порта Аи В(каждый с двумя целыми параметрами), причем первый порт А имеет более высокий приоритет, чем второй порт В.Если процесс затребует сообщение из разъема input, а там будет 2 сообщения (в обоих портах), то прочитается сообщение из порта А. Если в определении разъема порт не указан, то считается, что разъем имеет один порт, имя которого совпадает с именем разъема.

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

               Процесс, внутри которого определены подпроцессы (вложенные процессы), может задать определенную топологию соединений между разъемами своих подпроцессов (но только непосредственно вложенных в него!):

               – входные разъёмы родительского процесса могут быть связаны с входными разъёмами вложенных процессов;

               – выходные разъёмы вложенных процессов могут быть связаны с выходными разъёмами родительского процесса;

               – выходные разъемы вложенных процессов могут быть связаны с входными разъёмами этого же или других вложенных процессов (того же уровня вложенности!).

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

                 Приведем пример

process T = begin

    in a, b;                                                                                                                 

    out c;

 process X = begin

     in a, b;

     out c;

 end with a = a, b = Z. d, c = Z. a;                                                                                                                                     process Y = begin

     in a, b;

     out c;

 end with a = b, b = Z. d, c = Z. b;                                                                                                                                   process Z = begin

     in a, b; 

     out c, d;

 end with c =  c;

end

                  Обратите внимание, что, например, в описании процесса Х в записи with a=aпервое вхождение aобозначает собственный разъем процесса Х, а второе вхождение –разъем родительского процесса.

                   Процесс может читать сообщения из своих входных разъемов, а также из выходных разъемов своих непосредственно вложенных подпроцессов.

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

                  Описание процесса имеет следующую структуру:

process p = begin

                in входные разъемы;

                out выходные разъемы;

                data локальные переменные;

                let локальные обозначения;

                один или несколько обработчиков сообщений

end

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

                 Обозначение – это способ сокращения записи и экономии аппаратуры.

                 Рассмотрим пример

                 let ab = a+b

                 Далее ab в рамках текущего процесса можно рассматривать как полный эквивалент формулы a+b, которая будет заново вычисляться в каждом вхождении обозначения ab. Больше всего это похоже на макроподстановку, но есть и важное отличие – по записи let ab=a+b будет сгенерирован один сумматор, а все вхождения ab перейдут в «проводок», запускающий этот сумматор. В случае макрогенерации каждое вхождение ab порождало бы отдельный сумматор, что, разумеется, ухудшает эффективность.

                 Обработчик устроен следующим образом:

                 условие  {тело}

                 В условии принимаются сообщения. На основании успешности принятия сообщений принимается решение о запуске операторов тела.

Тело

                 Тело – это набор из последовательно исполняющих

                                                          {S₁; S ₂;...; S_m}

                 причем конструкции   {S₁; S ₂;...; S_m} исполняются в конвейерном режиме: если тело начало исполняться в каком-то такте (т.е. начала исполняться конструкция S₁), а для этого необходимо, чтобы условие в этом такте было истинным, то в следующем такте будет исполняться S ₂ . При этом и S₁ снова будет исполняться, если и в следующем такте условие будет истинным, и так далее. Если в каком-то такте условие ложно, исполнение  S₁ не начинается, но исполнение остальных конструкций продолжается (если они не приостанавливаются по каким-то своим внутренним причинам).

                Таким образом, возникает следующая картина. Одному телу   {S₁; S ₂;...; S_m} могут соответствовать несколько параллельно протекающих процессов, каждый на своем уровне конвейера, например,

                1) S₁;S₂;S₃;S₄;

                2) S₁;S₂;S₃;

                3) S₁;S₂;

                4) S₁;

                Здесь первый процесс дошел до исполнения оператора S₄ , а четвертый только начал S₁.

                А что же будет, когда исполнится последняя в теле конструкция S_m? Это означает, что закончена обработка данных, когда-то полученных в сообщении, запустившем S₁. Но за это время могло прийти много других сообщений, конвейер работает, пока не будет выключено электропитание.

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

                                                                   { P ₁| P  ₂|... |P _K }

                 Все P _i исполняются одновременно за один такт, причем они исполняются действительно параллельно, например, в {x: = y|y: = x} переменные x и y обменяются значениями(в начале такта будут прочитаны y и x, а в конце такта эти значения будут записаны в x и y).

                В качестве простейших операторов P _i могут использоваться следующие операторы:

               skip – пустой оператор.

                x : =E – присваивание, x – переменная, E – выражение (вполне традиционное без побочных эффектов). Присваиваниями нужно пользоваться аккуратно, т.к. разные экземпляры процессов конвейера будут присваивать значения в одну и ту же переменную.

                 x=E – локальное обозначение, x – локальное имя, E – выражение.Локальные обозначения «доживут» до использования в своем экземпляре конвейера, не вызывая никаких конфликтов, т. е., в каждом процессе конвейера будет действовать свое локальное обозначение.Именно поэтому использование локальных обозначений предпочтительнее использования присваиваний.

                   В отличие от конструкции let здесь нет никаких хитростей. Выражение E один раз вычисляется и запоминается в локальном обозначении x. Никто не запрещает использовать то же самое локальное обозначение x в новых описаниях даже других типов, но, разумеется, это вредит понимаемости («читабельности») программы.В этом случае старое локальное обозначение просто исчезает. Для тех, кто помнит Алгол 68, можно сказать, что x=E – это полный аналог описания тождества.

                    Условный оператор

if C ₁ then S ₁ elif C ₂ then S ₂...[else S _m] fi

                    Здесь C _1, C _{2  , ......... –}  условные выражения.

                    S _1,S _2,...S _m    – конструкции из параллельно исполняемых простейших 

                    операторов { P ₁| P  ₂|... |P _K }

                     Все C _1, C _{2, ...} И S _1,S  _{2, ...} исполняются параллельно за 1 такт, но семантика HaSCoL устроена таким образом, что видимый эффект (присваивание новых значений переменным, посылка сообщений) будет иметь только та конструкция  S _{k ,} условное выражение которой C _k выдало значение истина.

                    Условный оператор заимствован из языка Алгол 68.

                    inform m – ненадежная посылка сообщения m.

                   В операторе inform m доставка сообщения не гарантируется. После того, как сообщение послано, исполнение посылающего процесса продолжается без всяких условий (т.е. даже если сообщение никто не получил).

                   send E – надежная посылка всех сообщений, содержащихся в Е.

                   send – один из самых сложных операторов языка HaSCoL. Разберем его на последовательно усложняющихся примерах.

                   Пусть в каком-то процессе есть разъем

                    in input  (int, int) [A,B];

                   Тогда в обработчиках этого процесса может встретиться оператор

                   send input’ B (1,2)

                   input–имя разъема, B–имя порта этого разъема, (1,2) – фактические параметры посылаемого сообщения.

                  Если в разъеме, куда посылается сообщение, порты не определены, то подразумевается, что есть только один порт, имя которого совпадает с именем разъема, тогда имя порта в операторе send можно не указывать.

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

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

                   Рассмотрим примеры

                   send n (1) and m (2)

                   Здесь посылается сообщение с фактическим параметром 1 в разъем n и сообщение с фактическим параметром 2 в разъем m. Исполнение конструкции S , в которой встретился этот оператор send, будет продолжено, только если оба сообщения будут успешно доставлены. Если одно из сообщений будет доставлено, а второе – нет, исполнение S будет приостановлено, пока задержанное сообщение не будет доставлено тоже.

                   send n (1) or m ( 2)

                   Для продолжения работы нужно, чтобы хотя бы одно из этих сообщений было доставлено.

                    Заметьте, что оператор send m or true является полным эквивалентом оператора inform m.

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

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

                                                              P ₁ ---->P ₂ ---->P ₃ ---->P ₁

                   Здесь процесс P ₁ посылает сообщение процессу  P ₂ , который перепосылает его в P ₃ , а тот –снова в P ₁ ! Такие ситуации ловятся статически транслятором с языка HaSCoL.

Условие

                    В языке HaSCoLесть оператор посылки сообщения (даже два – send и inform), а оператора receive (получить) или ему подобного нет. Считается, что практически в каждом такте процесс может принять сообщения от других процессов (или от себя), поэтому роль оператора получения сообщения играет условие, с которого начинается каждый обработчик процесса. Пример условия:

                 m(a) when a>Ø

                  Здесь из разъема m принимается сообщение (если оно там есть), если параметр а этого сообщения больше Ø,то условие возвращает значение истина, и начинается исполнение тела. Если сообщения не было или параметр был меньше или равен Ø, то возвращается значение ложь, а исполнение тела приостанавливается.

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

                    m1[and C ₁] [when G ₁], m₂[ and C ₂ ] [when G₂ ], ... , m_k  [and C_k ] [ when G _k] 

                    Как обычно, запись [and C ] означает, что and C может отсутствовать, аналогично [ when G ]. Все  m имеют форму p ( n_1,...,n_m ) , где p – имя входного разъема, n_1,...,n_m – формальные параметры, соответствующие по количеству и типам параметрам данного разъема p. Если сообщение принимается, то формальные параметры получают в качестве значений фактические параметры сообщения.

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

                    Логические выражения C_i  играют другую роль – если сообщение может быть принято и  C_i истинно, то сообщение из этого разъема удаляется, иначе сообщение остается и может быть использовано еще раз. Если фрагмент and C _i  опущен, по умолчанию принимается истина.

                    Аналогичное умолчание принимается и для фрагмента when G_i .

                   Примеры:

                   m(a) ,  n(b)  when  a>b

                  Это условие истинно, если через входные разъемы m и n приходят сообщения и фактический параметр первого сообщения больше фактического параметра второго. Если все это выполнено, оба сообщения удаляются из своих разъемов.

                  m(a)  and a>0,  n(b)  when a>b – так же, как и в предыдущем примере, но из разъема m сообщение удаляется только, если фактический параметр больше Ø.

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

                  init – истинно только однажды при запуске системы (по сигналу reset);

                  default – истинно в начале каждого такта.

Пример

                 Продемонстрируем все вышесказанное на реальном примере –реализация очереди FIFO (первый пришел – первый ушел).

process Queue = begin

  in inp(int);

  out outp(int);

date buffer : [0..7 : unit (3)] int, 

           first : uint (3) = 0,                                  } date

           last : uint (3) = 0;

let notEmpty = first ! = last;    

let isFull = first == last + 1;                                } local bindings

let notFull = not isFull;

            default when notEmpty {                                             

                send outp (buffer[first]) | first: = first +1                    } handlers

                }

                inp (x) when (notFull  or (isFull and outp)) {                  

                         if not notEmpty then inform outp(x)                             } handlers

                         fi |

if notEmpty or not outp then buffer[last] := x | last := last + 1

fi

                      }

end

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

              uint – это беззнаковое целое,

              uint(3) – беззнаковое целое длиной 3 бита, т.е. числа от 0 до 7, заметьте, что для таких данных 7+1=0 (перенос пропадает).

              buffer – это массив из 8 целых чисел, его индексами служат целые числа типа uint(3).

              Таким образом, в этом примере описывается аппаратная реализация очереди FIFO с буфером из 8 целых элементов и двумя указателями first – индекс в очереди первого кандидата на отправку и last–индекс в очереди последнего не отправленного сообщения.

              Итак, описан процесс Queueс входным разъемом inpи выходным outp. Оба разъёма имеют по одному целому параметру. В процессе описаны переменные buffer, first и last, а также введены локальные обозначения not_Empty (очередь не пуста), is_Full (очередь заполнена полностью) и not_Full (в очереди есть свободные места).

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

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

               Использование идентификатора выходного разъёма в качестве аргумента логического выражения без намерения послать сообщение не описывалось ранее, это просто признак готовности разъёма к приёму сообщения.

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

                 В примере есть одна хитрость, которую без объяснений трудно понять. Речь идет об использовании во втором обработчике оператора inform вместо send. Дело вот в чем. Если в первом обработчике оператор send не сможет передать сообщение (выходной разъём не готов принять сообщение), обработчик приостановится и будет ждать момента, когда сообщение все-таки уйдет.

                 От приостановки первого обработчика никто не пострадает, очередь будет принимать сообщения во втором обработчике, пока не переполнится. Но если бы мы во втором обработчике использовали оператора send, то любая задержка в нем заблокировала бы дальнейшее заполнение очереди. Поэтому вместо sendиспользован неблокирующий оператор inform, а в конце добавлено условие or not outp. Если очередь была пуста, но входной разъем не был готов принять сообщение, то принятое из входного разъема сообщение могло бы потеряться, а с добавлением этого условия оно запишется в конец очереди по обычным правилам.

Список литературы

[1] A.Barabanov, M.Bombana, N.Fominykh, G.Gorla, A.Terekhov. Reusable objects for optimized DSP design.InEmbedded Microprocessor Systems, IOS Press, 1996

[2] D.Boulytchev, D.Lomov.An Empirical Study of Retargetable Compilers.In Perspectives of System Informatics, Springer Berlin / Heidelberg, 2001

[3] Д.Булычев, «Прототипированиевстроенныхсистемнаосновеописаниямакроархитектуры», диссертациянасоисканиеучёнойстепеникандидатафиз-матнаук, СПбГУ, 2004 г.

[4] W.Najjar and J.Villareal. Reconfigurable Computing in the New Age of Parallelism. SAMOS Workshop, 2009.

[5] R.D.Jianwen Zhu and D.D.Gajski. Syntax and Semantics of the SpecC Language. In Proceedings of the Synthesis and System Integration of Mixed Technologies, 1997.

[6] Celoxica. Handel-C Language Reference Manual, 2005.

[7] I.Page and W.Luk. Compiling Occam into FPGAs. “FPGAs”, Abingdon EE&CS books, pages 271-283, 1991.

[8] C.A.R. Hoare. Communicating Sequential Processes. Prentice-Hall International, 1985.

[9] Arvind, R.S.Nikhil, D.Rosenband and N.Dave. High-Level Synthesis: An Essential Ingredient for Designing Complex ASICs. In Proceedings of ICCAD, 2004.

[10] J. Hoe. Operation-Centric Hardware Description and Synthesis. PhD thesis, Dept. of EE&CS, MIT, 2000.

[11] G.M.Thorsten Grötker, Stan Liao and S. Swan. System Design with SystemC. Kluwer Academic Publishers, 2002.

  Маркетинг глазами практика

             Наше предприятие Терком образовано 14 февраля 1991 года, так что мой директорский стаж приближается к 20 годам. Первые контракты я получил по старым связям, т.к. более десяти лет перед этим я был зам.директора НИИ, работающего на оборонную промышленность. Но уже к концу 1991 стало ясно, что работать только по госзаказам попросту опасно, задержки платежей стали обычным делом, были случаи, когда по 3 месяца я не мог выплатить зарплату сотрудникам. Нас тогда было 30 человек, спасались моими лекциями в Гамбурге, я раздавал по 100 дойчмарок каждому, на эти деньги можно было жить месяц.

              На моё счастье, крупная итальянская фирма ITALTEL надумала установить связи с ЛНПО «Красная Заря», среди 20 приглашенных был и я, кроме меня никто не говорил по-английски (один товарищ говорил по-французски), но главным моим аргументом оказался Университет, итальянцы сразу оживились, на следующий день поехали в гости в Петергоф, мы получили крупный и интересный заказ, работали с ними более 10 лет, пока Сименс не выкупил их акции, убив тем самым одного из конкурентов.

              Еще более забавная история со вторым нашим западным заказом. Одна американская компания из Северной Каролины более двух лет носилась с идеей реинжиниринга, т.е. перевода старых программ, написанных на Коболе, ПЛ1 и других устаревших языках, на современные платформы. Прежде всего, они обратились в университет Дюка (очень известный университет в том же штате). Американские ученые исследовали этот вопрос и подготовили отчет, в котором утверждали, что практического решения эта задача иметь не может, т.к. надо тщательно исследовать графы зависимостей по управлению и по данным, а число путей в графах растет экспоненциально от числа вершин в графе.

              Как обычно, в этой американской компании не было ни одного руководителя, родившегося в Америке. Главный технолог был родом из Одессы, он предложил попробовать сотрудничество с русскими. Они написали письмо, буквально «на деревню дедушке», которое как-то попало ко мне, мы получили работу более, чем на 15 лет.

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

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

              Прежде чем излагать полученные и проверенные на практике крупицы знаний по продажам, обратимся к Википедии. В русской Википедии дается 6 определений понятий «маркетинг», из которых 2 наиболее близки мне.

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

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

              Основу работы отдела маркетинга составляет трубка заказов (pipe). Левый конец этой трубки должен иметь большой диаметр, который уменьшается по мере приближения к правому концу, поэтому иногда говорят воронка заказов (funnel). В широкий конец попадают наводки (инициативы, leads), т.е. просто самая начальная информация, что кто-то что-то хочет от нас. На самом деле, эти начальные наводки очень не просто найти. Возможно, вашу компанию порекомендовал один из ваших предыдущих Заказчиков (это самый лучший вариант), возможно, информацию о вас потенциальный Заказчик нашел на сайте компании или увидел информацию на выставке. Я больше всего верю в агентов, которые представляют ваши интересы в каком-то регионе, стране или группе стран, но об агентах мы поговорим позже. Начальные наводки (наши маркетологи все-таки говорят «лиды») традиционно называют наводками уровня С.

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

              Если переписка завязалась, наводка получает уровень В, мы пытаемся уточнить постановку задачи, посылаем резюме подходящих, на наш взгляд, сотрудников (без имен и телефонов, т.к. всегда надо опасаться рекрутеров). Именно на этом этапе впервые называют рейты, т.е. стоимость человеко/часа для каждой категории сотрудников. И здесь бывают потери, но если удалось все согласовать, то наводка получает уровень А, собственно, работа маркетологов на этом заканчивается и вступают продавцы (sales), который должны подготовить контракт и «дожать» Заказчика до его подписания. У нас главным продавцом является СОО, который к тому же руководит и отделом маркетинга, но я знаю и другие схемы.

               Надо понимать, что стабильность предприятия определяется наполненностью трубки заказов, часто путь от наводки уровня С к уровню А может занимать от полугода до года, а в Германии –и больше. В среднем, из 10-12 наводок уровня С получается одна наводка уровня А, причем наводки в трубке не просто лежат, а требуют большого внимания и постоянной переписки, разговоров по Skype и т.д. Именно поэтому регулярный маркетинг не под силу маленькой компании. Американцы говорят, что если хочешь заказов на $10 млн, то истрать $1млн на маркетинг и продажи.

              Такая простая идея, как трубка заказов, на практике обрастает массой проблем. Начнем с агентов. Хороший агент должен хорошо представлять себе возможности предприятия, которое пользуется его услугами. Он должен иметь широкий круг друзей, знакомых, бывших коллег в области IT. Кстати, именно поэтому редко бывают удачными попытки россиян работать агентами в западных странах. Агент должен обладать хорошо подвешенным языком и даром убеждения. Агент должен хорошо разбираться в текущей ситуации на мировом рынке, уметь доказать, в чём русские лучше, чем китайцы, индусы, вьетнамцы и т.д. Короче, хороший агент –это важнейший элемент цепочки продаж. Обычно агенты требуют зарплаты, причем хорошей по меркам той страны, в которой работают. Это опасно, так как у агента в таком случае нет никакого стимула, он может долго изучать рынок, ваше предприятие, находить кучу отговорок, почему нет заказов. Лучше всего вознаграждать агентов процентом от найденных заказов (5-10-15% в зависимости от объема и прибыльности заказа), но редко кто на это соглашается. Надо искать компромиссы, например, заранее договариваться, что оплачивается некоторый начальный период (3-6 месяцев) или на начальный период назначается более высокий процент. Возможны и другие варианты. Один датчанин предложил свои услуги целой группе компаний из РУССОФТа. За 2 года он почти ничего не нашел, все наши с ним разругались, а мы терпели. Зарплату мы ему не платили, но оплачивали командировки, публикацию рекламы, много раз ездили на встречи, которые он организовывал. В данном случае наши усилия и траты не пропали даром, он стал самым успешным из наших агентов.

             Другой пример. В Германии один из наших агентов работает, можно сказать, примитивно. Он обладает массой контактов, не долго думая, предлагает встретиться с профессором из Санкт-Петербурга, у которого работает более 300 человек математиков высокой квалификации. Я еду, часто с пересадками, скажем, в известную автомобильную компанию, а там глава IT-департамента индус, который с порога заявляет, что весь аутсорсинг они направляют в Индию, или еду в крупную компанию по производству бытовой техники, а им нужны только специалисты по SAP, которым мы не занимаемся. Я злюсь, спрашиваю агента, неужели он не мог узнать этого заранее. Он виновато пожимает плечами, но никаких выводов не делает. С другой стороны, мы уже имеем от него более двух десятков Заказов и наводок уровня В и А.

            Эти 2 примера я привел, чтобы показать, что работать с агентами очень не просто.

            Еще одна проблема, связанная с обработкой наводок, это оценка объема и стоимости предлагаемых работ. У нас в каждом департаменте есть 2-3 человека, которые занимаются этим делом, иногда на фоне их основной работы, а иногда это выделенные специалисты. Есть на предприятии и централизованная служба. Оценку надо делать быстро, максимум 1-2 дня, а лучше –часы. Понятно, что нужно просчитывать не только объем, но и разнообразные риски. Иногда мне кажется, что наши специалисты слишком много знают о рисках, они пытаются учесть каждую мелочь, в результате оценка делается неделю, и цена получается слишком завышенной. Заказ уходит к конкурентам, иногда мы узнаем, что они не справились с работой, но значительно чаще все проблемы удается разрешить, тогда бывает обидно, что мы упустили хорошую работу. Нужно уметь находить компромиссы.

             Самый острый вопрос – назначение цены. Называешь слишком много – не получишь заказа, слишком мало – не получишь прибыли.Умение правильно оценить работу приходит только с опытом. Я не думаю, что на Заказчика могут произвести впечатление какие-то сертификаты (кроме узкоспециализированных случаев – авиация, автомобильная промышленность, медицина и т.п.). Играют роль размер предприятия, его история, финансовая стабильность, но больше всего –успешные проекты в нужной Заказчику области.

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

             Одна из главных ошибок молодых компаний в процессе их роста – разделение маркетинга и производства. Пока компания была маленькой, генеральный директор сам занимался и поиском заказов, и организацией производства, поэтому он мог держать все детали в голове и быстро реагировать на все возникающие трения между Заказчиком и разработчиками. С ростом компании это становится невозможным, появляются специальные люди, целенаправленно занимающиеся маркетингом и продажами и почти всегда возникает следующая ситуация. Отдел маркетинга нашел наводку уровня С, довел её до уровня А, продавец продал (заключил контракт на работу), все, дальше пусть работает производство. Это и является ошибкой. На самом деле, маркетологов должна постоянно интересовать удовлетворенность Заказчика. Например, Заказчику не нравится какой-то разработчик, причем он приводит разумную аргументацию, лучше в такой ситуации сменить разработчика. Если Заказчику не нравится руководитель проекта, например, он плохо говорит по-английски или мелочится, неделю спорит с Заказчиком по пустякам, надо оперативно менять этого руководителя проекта. Американцы говорят, что продавец, сумевший подписать договор, должен обладать в пределах этого договора правами генерального директора. Мой опыт показывает, что это совершенно правильно. Продавец должен «держать руку на пульсе» в течение всего времени исполнения проекта, и после его завершения организовать так называемое «посмертное совещание» (postmortum meeting), на котором обсудить, что было хорошо, а что плохо, и попытаться получить положительный отзыв от Заказчика, который очень поможет в поиске новых заказов. Именно по этим соображениям я привел два определения маркетинга, первое вполне традиционное, а второе –более глубокое, на мой взгляд, охватывающее не только процессы поиска заказов, но и процессы производства. Я много раз рассказывал и молодым, и опытным менеджерам нашей компании анекдот про то, что Гиви гол забил, а Гоги утонул, хотя тренер кричал Гиви, чтобы тот отдал мяч Гоги. Вряд ли я буду радоваться, если команда завершит проект, мы получим причитающиеся нам деньги, но Заказчик при этом (чаще всего в приватной беседе) скажет мне, что работать больше с нами не будет, что наш менеджер – бюрократ (опять-таки, он использует совсем другое слово), а разработчики плохо отвечают на письма и т.д. Говорят, Эдисон так отбирал хороших инженеров. Приходит молодой специалист, Эдисон дает ему задание, скажем, на год. Если через год счастливый молодой специалист приходит к Эдисону и говорит, что он все сделал, и просит дать ему новую задачу, Эдисон его немедленно увольняет, считая, что за год хороший специалист сам придумает, что делать дальше. Я считаю, что с заказами ситуация абсолютно аналогичная. Каждый хорошо выполненный проект должен порождать еще один или несколько следующих проектов.

             В заключение рассмотрим еще одну схему взаимодействия с западными Заказчиками, которая уже показала свою эффективность. Если вам удалось в какой-то стране найти не просто агента-продавца, но маленькую (или большую, это не важно) фирму, специализирующуюся в той же области, что и ваша компания, возможна следующая схема. Компания-партнер находит Заказчика и заключает с ним договор на себя. Надо признать, что проклятые охотнее заключают договоры с западными же партнерами, чем с русскими. С вашей компанией компания-партнер заключает договор на разработку, а постановка задачи, общение с Заказчиком в процессе разработки, установка ПО (deployment), обучение пользователей, т.е. как раз все фазы, где нужно тесно общаться с Заказчиком на месте, остаются за компанией-партнером. Разумеется, здесь уже не идет речь о 15% агентских. Компания-партнер возьмет себе как минимум 50%, но и головной боли у вас будет существенно меньше. Не забывайте, что 50% будут браться совершенно от другой суммы, компания-партнер заключит договор по другим ценам, чем можете заключить вы.

            Компания-партнер будет осуществлять управление вашими программистами, часто наши ворчат, что проклятые их достают. Надо объяснять, что лучше перенимать этот опыт, это даже лучше, чем учиться в какой-то бизнес-школе (конечно, я не имею в виду Лондонскую, Стокгольмскую, Бэркли или им подобные). Во всяком случае, мы учились именно так.

            Буду рад прочитать любые комментарии к этому опусу, как от молодых, так и от старых, от новичков и от умудренных опытом.