TeleBolkNote

Brainfuck: оптимизирующий интепретатор Удивительно, как некоторые бесполезные идеи иногда накрепко захватывают наш ум. Я тут в качестве примера хотел привести игру «Жизнь» Конвея, но при всей своей кажущейся бесполезности она в своё время сильно продвинула математику. Меня в своё время захватила идея языка программирования «Брейнфак». Оглядываясь назад, думаю, её тоже нельзя объявить полностью бесполезной: в своё время я немало поломал голову над созданием оптимизирующего интерпретатора для этого языка. Для начала — про сам язык. Я узнал о нём примерно в 2000 году, когда была мода на так называемые «эзотерические языки» — языки, разработанные в качестве шутки или для исследования какой-нибудь абсурдной идеи. «Брейнфак» как раз из таких: в нём всего восемь инструкций, но при этом это полноценный язык. Нейросеть мне на нём даже написала «Тетрис». «Брейнфак» оперирует ячейкой в массиве, индекс которой можно сдвигать при помощи конструкций < и >. Кроме того, ячейку можно декрементировать (-), инкрементировать (+), вывести на экран символ, код которой записан в ячейке (.), либо записать код введённого с клавиатуры символа (,). Кроме того, в «Брейнфаке» можно организовывать циклы при помощи парных инструкций [ и ] неограниченной вложенности. [ проверяет значение текущей ячейки, если там не ноль, выполняет тело цикла. Например, [-] записывает в текущую ячейку ноль, декрементируя значение в цикле. Так как это единственная управляющая конструкция, циклов в обычной программе на «Брейнфаке» — огромное количество. Например, вот так выглядит минимальный «квайн», программа, которая при запуске выведет саму себя: ->++>+++>+>+>++>>+>+>+++>>+>+>++>+++>+++>+>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>+>+>+ +>>>+++>>>>>+++>+>>>>>>>>>>>>>>>>>>>>>>+++>>>>>>>++>+++>+++>+>>+++>>>+++>+>+++>+ >++>+++>>>+>+>+>+>++>+++>+>+>>+++>>>>>>>+>+>>>+>+>++>+++>+++>+>>+++>+++>+>+++>+> ++>+++>++>>+>+>++>+++>+>+>>+++>>>+++>+>>>++>+++>+++>+>>+++>>>+++>+>+++>+>>+++>>+ ++>>+[[>>+[>]+>+[<]<-]>>[>]<+<+++[<]<<+]>>

Отпуск начался Ну всё, дожил до отпуска. Осталось его пережить. Вылетали из России вечером, прилетели во Вьетнам утром, но вьетнамским утром, по России мы прибыли в два часа ночи. Сидели мы на местах с увеличенным пространством для ног, что в моём случае оказалось минусом — я очень плохо сплю в самолётах, как правило упираюсь лбом в следующее сиденье и дремлю, а тут этого сиденья впереди просто не было. Во Вьетнаме пасмурно и дождь. Такое мы видели и на родине. Правда, тепло — около 30°, в Казани сейчас, наверное, вдвое холоднее. Очень хочется спать, но негде — номер ещё не готов.

Хаки в «Электронике МК-61» Очень интересно разбирать хаки, которые разные люди изобретали, чтобы уместить свои программы в 105 байт памяти калькулятора «Электроники МК-61». Их там действительно просто нереальное количество, они разной сложности, но один из них показателен в своей простоте. В коде программы «Рембо-III» есть несколько похожих мест (я буду приводить код на языке «МК-Про» для наглядности): fn lost() { halt("ЕГГОГ") } fn front_stop() { … if cells[7] < 0 { lost() } … } Если некое проверяемое значение меньше нуля (в двух остальных местах — меньше или равно нулю), то пишем на экране «ЕГГОГ» — слово «error», это одно из немногих слов, которое калькулятор способен отобразить, так как у него есть специальная логика для отображения некоторых букв, поэтому его часто используют для обозначения проигрыша. Мой оптимизатор умеет заменять halt("ЕГГОГ") одним опкодом, потому что это «встроенное» в калькулятор слово, но тут он пишет относительно много кода — проверка условия и вызов, тогда как проверку и вывод «еррора» можно объединить в один опкод — F √ или F lg в зависимости от условия. Если число строго меньше нуля, квадратный корень из него даст ту же ошибку, как и логарифм от числа, которое меньше или равно нулю. В «Рембо-III» это сокращает программу на четыре байта. Это существенно, когда у доступно так мало памяти.