Моя вторая ЭВМ(уже почти компьютер)
Ну, про "Наири" написал, теперь можно запилить и продолжение.
В общем, попал я на завод. В отделе обнаружилась .. та-дамм! Кто бы мог подумать, ЭВМ.
А если быть более точным - то микро-ЭВМ "Электроника-60М".
Вот примерно такая:
Правда, она была встроена в стойку, но вот эта панель присутствовала.
Периферия была почти та же, что и у "Наири": перфоратор, фотосчитыватель, и ... ура! Вместо пишущей машинки "Consul-254" был дисплей! Венгерский "Videoton".Правда, алфавитно-цифровой, и всего на 16 строчек, но уже гораздо приятнее, чем пишущая машинка. Вот такой примерно:
Да и памяти у этой микро-ЭВМ уже было не в пример больше, чем у "Наири": целых 56 килобайт!
Правда, из них 32 кб занимала операционка, и ещё 16 кб массив данных, так что на наши прикладные программы оставалось 8 килобайт.
Казалось бы, что можно втиснуть в такой маленький объём?
Так вот, я вам скажу: втиснуть можно довольно много, если программируешь на языке, максимально приближенном к машинному, а именно на ассемблере.
О да, мы экономили каждый байт! Во время этой работы я много узнал о методах оптимизации машинного кода. Например, один из приемов был такой: сама команда использовалась в качестве операнда, если её двоичная структура имела нолики и единички в нужных местах. Так мы экономили аж целых два байта! Широко использовался метод табличного программирования, когда адрес перехода вычисляется в зависимости от результат предыдущей операции. А когда один из наших коллег выяснил, что команда перехода по циклу мало того, что имеет ограничения по глубине этого цикла, так ещё и выполняется на порядок дольше, чем пара "вычитание счетчика - ветвление на начало цикла", мы повсеместно начали её заменять на эту пару. Да, мы теряли на этом пару байт, но зато выигрывали в быстродействии.В конце концов, всё втиснули в эти 8 килобайт, а результатом было отображение нужной информации на экране у оператора.
Эх, хорошая была архитектура фирмы DEC, известная, как PDP-11. Правда, всего лишь 16-разрядная, но всё же, всё же...
Но программирование оставалось непростым процессом: сначала с перфоленты грузишь "редактор", в котором набираешь программу, затем выводишь её на перфоленту. Грузишь с перфоленты компилятор, ему скармливаешь перфоленту с текстом программы, на выходе получаешь ещё одну перфоленту. Но это ещё не та, с которой можно запускать программу!
Грузишь с очередной перфоленты линкер(компоновщик), ему скармливаешь предыдущую перфоленту - и, наконец-то, на выходе имеешь перфоленту с запускаемой программой!
Запускаешь ... не работает, мысленно материшься и ищешь ошибку. Найдя - весь процесс повторяешь сначала. Как говорится, "далее по циклу" - пока программа не заработает.
Был у нас в стойке с "Электроникой-60" магнитофон. Вроде как лучше бы с него грузиться, перфоленты-то часто рвутся, всегда стараешься сделать хотя бы одну запасную копию...
Но с магнитофоном сначала как-то не получалось: при попытке перезаписать перфоленту на магнитофон, она, конечно, записывалась, но при попытке загрузиться - сначала всё шло нормально, но в самом конце - сбой, кассета в магнитофоне перематывалась в начало и снова пыталась загрузиться... и опять "далее по циклу".
Пришлось разбираться с этой проблемой.
Причина оказалась банальна: код в конце загрузки затирал загрузчик, ну и, сами понимаете, всё начиналось сначала. Поломав голову, я решил проблему так: модифицировал код загрузчика таким образом, что он стал грузить программу немножко в другие адреса, а в конце загрузки, когда вся программа уже в памяти, срабатывал кусочек кода, который перемещал программу в правильные адреса, также затирая загрузчик - но он уже был не нужен.
Это сработало, и теперь мы стали грузиться с магнитофона.
Не передать, какое это было облегчение и упрощение процесса :)
Перфолента-то то порвется, то какое-нибудь место не прочитается, то ещё что-нибудь.
В общем, приключений было много :)