Как программировали в 60-70 года прошлого века на примере написания и отладки программ в машинных кодах ЗВМ “Минск-22” - Личное - Блог - О семье Дедусенко и связанных с нею семьях

Все что сейчас пишут о программировании в машинных кодах, полная чепуха. Вот яркий пример изложения таких взглядов :
   “ В самом начале у компьютеров не было даже клавиатуры! То есть всё было очень плохо — у них не было ни клавиатуры, ни экрана, были перфокарты (это такие штучечки с дырочками или с отсутствием дырочек). И программы в то время писали с помощью машинных кодов — у каждой операции в компьютере был какой-то машинный код . Люди сами по табличке!!! выбирали этот код, всякие адреса в памяти, всё это выбивали руками и засовывали в считыватель — и оно всё считалось. Конечно, работа программиста была, наверное, тогда не особо интересной — проделывать дырочки — и с развитием науки и техники, конечно, начали придумывать всякие, более «интересные» штуки. Например, ассемблер который уже несколько облегчал жизнь.
   Постепенно, становилось понятно, что разрабатывать так большие сложные программы очень сложно. Производительность программиста в этих командах была предельно низкой — то есть он писал несколько строк в день (осмысленных), и каждая строка ничего особо и не делала — какие-нибудь простые арифметические действия. И людям хотелось сделать языки гораздо более похожими на человеческий язык, на английский в частности, чтобы писать программы было легче и удобнее." И пошло-поехало!
   Более идиотского описания процесса програмирования в 60-70 годах я не встречал. Хотя бы подумайте, как и кем писались первые языки программирования и операционные системы? И в каком коде ?   И чем латинские буквы и английские слова в командах ассемблера лучше чисел в машинном коде? Я лично изучал в школе немецкий и мне английские слова ничего напоминают и для меня значительно легче запомнить цифры. И написать я мог до 300 строк сложного кода в день ( но день мог быть и 16 часов если надо ), а если простого то 500 строк, И 99,9 % кода были логические операторы и операторы работы с информацией, а не арифметика.

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

Вот как раз тогда работа классного программиста была невероятно интересной и для окружающих даже загадочна. Теперь что бы выучить любой ЯП (язык программирования) с нуля и врубиться в суть проблемы нужно изучить минимум 10 000 страниц разных текстов и пройти какие-то практические курсы. А тогда ты выучил и понял как работают команд 30 и запомнил их навсегда, да еще 50 команд на у тебя на табличке и все. 90% из этих 50_ти ты используешь раз в год или никогда, но знаешь что они есть. Ну почитал там книжку "Программирование на ЭВМ-22", ознакомился с пультом управления машины - вот и вся учеба. Но любые знания не сделают из тебя классного программиста. Это или дано или не дано. На фото моя личная табличка с командами ЭВМ "Минск-22" с кляксой на одной очень нужной команде.

Если работает правильно голова, то теперь ты царь и бог ЭВМ. А если ты еще и креативен и у тебя безупречная логика, то можно было стать программистом экстра-класса за 1 год. Но следует заметить,что отношение программистов экстра-класса и простых программистов-кодеров было тогда 1 к 50. То есть на одного классного программиста приходилось 49 кодеров разной степени способности. Теперь я думаю, это только один настоящий программист из 1 000 кодеров. Я доказано писал программы в 500 раз быстрее чем простые кодеры. Это было на пике моей формы на третий год работы программистом. Хотя разница в зарплате тогда у меня с ними была советских 10 рублей. Это было тогда 3 бутылки водки.

Классных программистов в первые годы работы СКБ системотехники ПО"Электрон", что было тогда во Львове. было всего два. Моя нач. отдела и Ваш покорный слуга.  Многие правда считали иначе и мне приходилось участвовать в разных спорах и дуэлях.Это сейчас называется баттл. И я всегда был победителем.   Манеры программирования у нас с моим начальником были разные. Она не была моим учителем. Ее манера писать программы была похожа на виртуозное вязание на спицах, а моя как отражение способа мышления структуральнейшего лингвиста из писаний братьев Стругацких.

В то время уже были разные автокоды, Алголы, Фортраны и Коболы, но мы ими никогда не пользовались в настоящих разработках. Я не говорю сейчас о математике и технических расчетах, а о разработке систем управления для предприятий,банков,складов и т.п. При минимальных возможностях тогдашних ЭВМ ценился каждый свободный бит в ОЗУ и каждая минута машинного времени отладку и работу программы. Так что применение языков было невозможно по уважительным причинам. Зато таких спецов умеющих писать в двоичном коде в США уже почти не было и наших евреев программистов после переезда в США брали на очень высокую зарплату.

В СССР тогда пошли другим путем. Программисты экстра-класса писали стандартные программы (СП), а простые программисты или даже постановщики задач собирали из них целые задачи как из детских кубиков. СП это то ,что сегодня называется процедурой с большим числом передаваемых в нее параметров. Никто почти никогда не писал специальных программ. Задача которая писалась и мучительно отлаживалась на Коболе три месяца, при применении СП создавались за пару недель,легко отлаживались и переделывалась. Это по сути было программирование без программиста,о котором на Западе заговорили только в 80 годах. Если тогда мы продолжили бы развитие собственных ЭВМ с режимом эмуляции Минск-22, тогда мы бы не отстали бы так от Запада.
   Стратегия академика Глушкова предусматривала использование готовых разработок с их дальнейшим развитием. Базой развития служили машины семейства «Наири»,которые стали достойным ответом западным ЭВМ. Эта машина могла эмулировать код любой ЭВМ и этот процесс был в разы быстрее чем сегодняшние системы с их бесконечными переводами кодов до уровня исполняемых. Но его не послушали в ЦК КПСС и выбрали тупиковый путь ЕС ЗВМ. Все что было написано раньше , выкинули на помойку и начали все сначала.При этом потеряли былую скорость программирования. В моем же отделе программы к задачам вместо 2-3 недель стали писаться и отлаживаться 6 месяца. А еще через 15 лет выбросили и сами ЕС ЭВМ и программы к ним. Заводы загнулись ,объемы производства резко упали и все ,что осталось перешло на персональные ЭВМ. Да и сами ЭВМ единой серии настолько плохо работали,что ходили упорные слухи ,что американцы специально вставили в аппаратную часть неявные ошибки. ЭВМ вроде и работает, а сути мучает людей остановами каждые пять минут и зависаниями.

Что же представляла собой ЭВМ “Минск-22” ? Оперативное запоминающее устройство (ОЗУ), составляло порядка всего 37 кбайт с производительностью центрального процессора 5-6 тыс. операций/сек. Данная ЭВМ комплектовалась внешней памятью на магнитной ленте (8 лентопротяжных механизмов) по 100 тыс. слов на 1 катушку или 3 600 000 тыс. байт ( 3,6 мбайт, это как рядовая фотка сегодня ). , внешними устройствами с носителями информации на бумажной основе (перфоленты, перфокарты) и АЦПУ (печатающее устройcтво) которые выдавало на рулонную бумагу формата А3 до 400 строк в минуту. Вот эти машины снимках. В машинном зале две ЭВМ “Минск-22” в полной комплектации.И, к счастью, на этих компьютерах не было раздутого ПО. Наличие всего 37 888 байт напрямую адресуемой ОЗУ отлично стимулирует концентрацию мозга!

На фото слева плата ЭВМ "Минск-22" . Это одна ячейка памяти этой машины размером в 4,5 байт (37 бит !!! ). Для сравнения привожу современный одноплатный компьютер C.H.I.P. стоимостью $9. На борту уже содержатся процессор в 1 ГГц, 512 Мб памяти, накопитель на 4 Гб, Wi-Fi и Bluetooth адаптеры, а также композитный видеовыход. Так вот, 1 GHz — один миллиард операций в секунду. На фото есть компьютеры и подороже. По 10 и 15 долларов


За 50 лет скорость и память дешевых и простых ЭВМ увеличилась в млн. раз. Но две ЭВМ “Минск-22” легко справлялись с обслуживанием завода численностью 50 000 человек, а простые и дешевые персоналки,даже связанные между собой , с этим не справятся. Дело в том ,что ЭВМ «Минск-22” умела вводить и выводить горы документов. Например,для печати лимитно-заборных карт использовалась бумага в специально заказанных на бумажной фабрике рулонах весом 500 кг. АЦПУ сжирало этот рулон за 6 -8 часов. Каждый день в ЭВМ Минск-22 вводились горы информации,заранее подготовленных 20 операторами на перфолентах и т.д. Да и машинное время современных машин в основном расходуется на управление и свое же обслуживание. Сколько времени работают собственно исполняемые программы никто толком не знает. Современная ЭВМ с софтом вещь в себе.
А тогда ты мог видеть даже как работает одна команда по частям (тактам). Ну там команда вызвала содержимое первой ячейки в 1 регистр (память команды),затем вызвала содержимое второй ячейки в 2 регистр, потом ты видел результат работы команды в сумматоре и лишь потом он записывается куда указано. Это особенность мною широко использовалась при отладке сложных программ. Тогда программист имел доступ к каждому биту в ОЗУ и во внешней памяти. Мы можем сейчас сравнить два драйвера к дисплеям. Тогда в СКБ системотехники проектировались дисплеи для ЭВМ "Наири" и меня часто ребята-электронщики ,товарищи по курилке, просили по быстрому написать драйвер к очередному черно-белому шедевру. Так вот ни один драйвер у меня не получался длиннее ,чем 300 байт вместе таблицами символов в двоичном коде. А сейчас код драйвера к любому дисплею составляет в среднем 1 000 000 байт. Моя программка была короче в 3000 раз !!!    А вот интересно какой длины был исходник у этих драйверов. Если он был,например, даже 3300 байт (больше чем в 10 раз) , то один байт в коде исходника превратились в 330 байт кода исполняемой программы.

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

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

Ну ладно,продолжим. На специальном бланке от руки писалась программа. Вот окончательный код такой программы,написанный моей рукой с пояснениями. Это была очень важная подпрограмма чтения-записи информации на МЛ. Она была длиной в 40 команд (180 байта) и она полностью управляла процессом обмена ОЗУ с памятью на МЛ. Если в СССР и была такая подпрограмма, то я о ней никогда не слышал. Она увеличила скорость написания программ раз в 10. Я ее писал 2 суток,а доводил до совершенства месяц. Из первоначальной версии в 200 команд мне удалось оставить только 40. При этом широко использовалась запись констант в тело команды и другие невероятные приемы. На фото текст этой подпрограммы на бланке. Коды написаны в восьмеричной системе и их число в этой системе , как вы можете видеть равно 50. Это подпрограмма дала начало моей собственной библиотеке стандартных программ и подпрограмм для ЭВМ “Минск-22”. Из чужих разработок использовались только минская сортировка на МЛ и в ОЗУ и подпрограмма деления ( в ЭВМ Минск-22 не было команды деления в десятичной системе). На фото чистовой текст этой подпрограммы написанный моей рукой и он же после ввода и распечатки на АЦПУ. На фото можно кликнуть для увеличения.

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

Информацию для реальной работы в АСУП «Львов” набирали на обычных телетайпах производства ГДР , в коде МТК-2, который был основан на международном телеграфном коде № 2 (ITA2), Он был пятибитный. Каждая строчка в перфоленте была кодом от 00000 до 11111. Например двоичный код 11101 в разных регистрах означал буквы Q или Я,или цифру 1. Вот фото из бюро подготовки информации АСУП « Львов”.

Каждый уважающий себя программист мог бегло читать перфоленты в двоичном коде и коде МТК-2 на свет. Это было как азбука Брайля для слепых,только вместо пальцев мы “щупали” глазами дырочки в перфолентах. Иначе как узнаешь ,что за перфолента у тебя в руках перед вводом. Или твоя программа или чужая,или накладные на материалы. А может быть рисунок Моны Лизы для вывода его на АЦПУ.  Да и зачастую исправляли ошибки в данных на перфолентах путем прокалывания новых дырочек специальным дыроколом,а единички заклеивали маленькими бумажками от пробивки дырочек.
.

Каждому программисту выделялось машинное время на отладку.Это сейчас у каждого есть свой комп в сети и отлаживай сколько хочешь и можешь. А тогда на две ЭВМ «Минск-22” при разработке АСУП «Львов”было около 100 программистов разработчиков. Большую часть времени занимало решение собственно задач АСУП, а вечера и ночи и выходные дни отдавались под отладку новых разработок. Обычно каждый программист имел пару часов в неделю. Средств отладки еще не было, потому не было и листингов с результатами отладки. Отладка производился в реальном времени. Обнаруживались разные ошибки. Это были ошибки ввода,логические ошибки,ошибки в кодах и т.д. Часть из них исправлялась руками на пульте управления ,часть искалась за столом и это занятие занимало большую часть рабочего времени программиста. Вот пульт управления ЭВМ “Минск-22”.

Когда я увидел пульт ЭВМ "Минск-22" в первый раз,то был в шоке. Сотня мигающих лампочек и кнопок, на которые программист или оператор быстро-быстро нажимают. Но потом оказалось, что только так кажется. что это сложно. Лампочки это три регистра по 37 бит в каждом и на каждый бит своя лампочка. Лампочка горит это "1" ,не горит это "0". то же и с кнопками. Нажата - "1".не нажата -"0". Вот сидишь и если надо набираешь 37-значный код ручками. нажимая нужные клавиши. При опыте работы это делалось, не думая о руках. за 2-3 секунды. Часто короткие подпрограммы вообще набирались вручную. Это было быстрее чем бежать на УПД и там набивать код на перфоленту,а затем вводить в ЭВМ. Были десятки и других кнопок и лампочек. Нужно было управлять кучей устройств: протяжками МЛ, АЦПУ, БММ, перфоленточным вводом и выводом. и т.д. Нужно было самому ставить и менять тяжелые катушки с МЛ.  И нужно было помнить какую и когда ленту ставить или менять. Нужно было заправлять бумагу в АЦПУ и следить что бы ее не замяло. Нужно было заправлять катушки с перфолентами и делать многие другие вспомогательные работы. На на фото ниже идет не отладка программы, а решение одной из задач АСУП. Одна из женщин операторов за пультом,а другая возится у лентопротяжек. Лента перематывалась, помещая ленту в огромные карманы (они видны на фото) и с громким шелестом моталась туда-сюда, считывая и записывая информацию маленькими порциями,потому для нее не было места в ОЗУ. Вообще в машинном зале было шумно, как в цехе.Шумело и гудело все, но особенно гремело АЦПУ. Оно весило 800 кг. и хотя было вделано в бетон, при печати дергалось и грохотало как небольшой кузнечный молот.


Самой неприятной обязанностью каждого программиста было сгонять своего предшественника с машины. Ему или ей как всегда не хватало пару минут,что бы закончить какой-то этап своей работы. Но когда эти пару минут проходили,то оказывалось,что ему нужно еще пару минут, а твое время тает на глазах. Доходило до ссор и даже очень редко , до драк. Но машинного времени все равно не хватало и мы арендовали его в других ВЦ во Львове и даже в других городах Я лично одно время имел машинное время в статуправлении г. Минска. Вот там можно было посидеть на машине в выходные и двое суток подряд. Да и во Львове иной раз приходилось заниматься срочной отладкой 2-3 суток подряд не выходя из ВЦ. Ну там поспал пару часов на канцелярском столе и опять к машине.

Но действительно,что было особенно неприятно, это постоянные поломки ЭВМ "Минск-22". Я работал на десятке таких машин и все они чем-то отличались друг от друга (изделие серийное,но вместе с тем и штучное), но в одном они были похожи. 30% машинного времени уходило на ремонт самых разных устройств из комплекта этой ЭВМ и самое главное на повторы работы программы из-за сбоя процессора. Вы себе и представить не можете нашу злость на машину,когда из-за её сбоя приходилось начинать сначала работу какой-либо программы с контрольной точки после ее непрерывной работы в течении нескольких часов.    Обычно это было к утру после бессонной ночи во время испытания задачи на реальной информации. Чаще всего это была сортировка больших массивов на 4 МЛ. Это было просто невыносимо. Ночь не спал и время ушло впустую.

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

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

Продолжение поста в статье:  Как я стал системным аналитиком и программистом в АСУП "Львов"

P.S. Я чистым программистом-кодером не был никогда. Разница между этими понятия, как у дирижера симфонического оркестра и простыми музыкантами. Системным аналитиком я был всегда,что позволяло мне занимать при СССР должности нач.отдела НИИ. зама Главного конструктора АСУ в оборонке. главного инженера НИИ, а после развала оборонки и место директора по экономике и финансам СП (с немцами). Параллельно первые 10 лет работы и последние 10 работы я занимался и кодированием. Сначала в машинных кодах Минск-22, а последние 10 лет на VBA Ексель. Молодежь считает программирование на VBA уделом лузеров.   Но для меня было важно опять вернуться к созданию самомодифицирующего кода программы, вернее его части в табличной форме. Программа пишет программу!!!
   При этом нет необходимости решать комплекс тех проблем; которые возникают при создании проектов в случае применения других языков — организация ввода и вывода данных, оформление интерфейса и диалога с пользователем, построение графиков и т. д. Мало того,  стандартные элементы управления имеют ряд свойств, которые связаны с объектами электронной таблицы, то есть обеспечивают взаимодействие VBA и офисного приложения. Важно также, что ячейки ЭТ можно рассматривать как ячейки памяти ЭВМ и что позволяет писать на VBA Ексель как писали раньше в машинных кодах. В инете встречаются статьи о стариках-программистах ,которых зовут богами Ексель. Это ведь не случайно. У молодежи нет навыков чистого программирования. Технологии абсолютно другие и применяя их ты не бог вовсе, а раб этой программы (языка, библиотеки). Visual Basic был (и вероятно остается) первым из числа самых популярных языков программирования всех времен; для разработки под Windows программисты обычно отдают предпочтение ему, а не С или С++, Даже в основе языка программы 1С лежит опять же VBA.
  Однажды ко мне в гости однажды зашел один лучших программистов нашего НИИ в последние годы его работы при СССР. Не знаю его уровень в наше время. Но он имел постоянную работу по специальности где он применял современные технологии программирования. А я тогда написал очень сложную офисную программу на VBA . И я спросил у товарища, сколько бы ты писал такую вещь по времени?  Он мне ответил: - где-то год! - А я написал и отладил за неполный месяц.   Ничего не изменилось под Луной. Я пишу программы быстрее чем многие современные программисты. У меня был рекорд на пике формы в 27 лет от роду.Тогда я на спор написал программу в 500 раз быстрее чем один старший инженер-программист. А сегодня могу только раз в десять быстрее.   Замечу,что мне уже за 70 лет. Но это  возможно для меня в только в той предметной области, в которой я специализируюсь. А это экономические и финансовые расчеты, задачи управления производством, логистикой и запасами ТМЦ , любые офисные программы. Вообще так можно написать любую программу и для многих других областей знаний.
     Вот пример такой программы, написанной мною для себя и которая очень полезна людям с диабетом или с излишним весом. Компьютерная программа "Диабет-2018". Расчет и оценка диет и доз инсулина для диабетиков. Программа "Диабет-2018" написана на подмножестве языка Visual Basic - Visual Basic for Applications ( VBA). Базой данных для этой программы являются таблицы в формате Ексель любой версии выше 2002 ! Т.е. 2003-2016. Программа не коммерческая , полностью бесплатная и потому все коды программы и базы данных открыты и не защищены паролями. Там нет только примеров, как программы пишут себя сами. Научитесь сами, тоже будете Богом Ексель или обычным академиком.  Вот щелкните на мое фото и узнаете как им стать.