Теперь работа Мэла состояла в переписывании блэкджека под RPC-4000. (Портирование? А что это такое?) Новый компьютер имел схему адресации «один плюс один»: каждая машинная инструкция, помимо кода операции и адреса операнда, имела дополнительный адрес, указывающий, где на вращающемся барабане расположена следующая инструкция. В современных терминах - за каждой инструкцией следовала команда GO TO. Каково, а? Забейте этой дурью трубку Паскаля и как следует затянитесь, чтобы осмыслить!
Мэлу нравился RPC-4000. На нем можно было оптимизировать код, размещая инструкции на барабане таким образом, чтобы по завершении одной вторая могла бы выполниться немедленно. У нас была специальная программа для этих целей, оптимизирующий ассемблер, однако Мэл отказался ее использовать.
«Никогда не знаешь, куда и что он запихнет», - объяснял он, - «и придется использовать дополнительные константы».
Прошло немало времени, прежде чем я понял эту ремарку до конца. Мэл знал числовое значение каждого кода операции и мог назначать собственные адреса на барабане. А каждую написанную им инструкцию можно было рассматривать как числовую константу. К примеру, он мог взять инструкцию сложения (если, конечно, она имела нужное значение) и умножить на неё другое число. Так что работать с кодом Мэла мог только сам Мэл.
Я сравнивал программы Мэла, оптимизированные вручную, с результатами оптимизирующего ассемблера на том же исходном коде. И результат Мэла всегда оказывался лучше. Думаю, всё из-за того, что метод разработки «сверху вниз» еще не был изобретен. А если бы и был, Мэл все равно отказался бы его использовать.
В первую очередь Мэл писал самые сложные фрагменты программных циклов, чтобы первыми разместить их на оптимальных адресах барабана. Наш оптимизирующий ассемблер был не настолько хитер и дальновиден.
Кроме того, Мэл никогда не использовал циклы, чтобы создать задержку в выполнении кода - даже если неуклюжему Flexowriter’у для корректной работы требовался перерыв между выходными символами.
Мэл размещал инструкции на барабане таким образом, чтобы каждая из них проходила мимо считывающей головки строго в нужный момент.
Мэлу нравился RPC-4000. На нем можно было оптимизировать код, размещая инструкции на барабане таким образом, чтобы по завершении одной вторая могла бы выполниться немедленно. У нас была специальная программа для этих целей, оптимизирующий ассемблер, однако Мэл отказался ее использовать.
«Никогда не знаешь, куда и что он запихнет», - объяснял он, - «и придется использовать дополнительные константы».
Прошло немало времени, прежде чем я понял эту ремарку до конца. Мэл знал числовое значение каждого кода операции и мог назначать собственные адреса на барабане. А каждую написанную им инструкцию можно было рассматривать как числовую константу. К примеру, он мог взять инструкцию сложения (если, конечно, она имела нужное значение) и умножить на неё другое число. Так что работать с кодом Мэла мог только сам Мэл.
Я сравнивал программы Мэла, оптимизированные вручную, с результатами оптимизирующего ассемблера на том же исходном коде. И результат Мэла всегда оказывался лучше. Думаю, всё из-за того, что метод разработки «сверху вниз» еще не был изобретен. А если бы и был, Мэл все равно отказался бы его использовать.
В первую очередь Мэл писал самые сложные фрагменты программных циклов, чтобы первыми разместить их на оптимальных адресах барабана. Наш оптимизирующий ассемблер был не настолько хитер и дальновиден.
Кроме того, Мэл никогда не использовал циклы, чтобы создать задержку в выполнении кода - даже если неуклюжему Flexowriter’у для корректной работы требовался перерыв между выходными символами.
Мэл размещал инструкции на барабане таким образом, чтобы каждая из них проходила мимо считывающей головки строго в нужный момент.
https://habr.com/ru/company/ispsystem/blog/596369/
Reply
Leave a comment