МК-Про

Вышла версия «ГПТ-6 Астра», судя по информации в интернете, значительно лучше предыдущей версии — 5.6, но пока в своих проектах я не ощутил какого-либо заметного улучшения. Для тестирования моделей у меня есть специальная сложная задача — оптимизирующий компилятор, который преобразует высокоуровневый язык программирования «МК-Про» в машинные команды калькулятора «Электроника МК-61».

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

Две программы, пока не поддающиеся полной оптимизации — «Крестики-нолики 4×4» и «Некромант».

Сейчас у меня есть две программы, которые пока не удалось успешно оптимизировать — это игры «Крестики-нолики 4×4» и «Некромант». Суть задачи состоит в том, чтобы нейросеть запрограммировала оптимизатор таким образом, чтобы он узнавал какие-то общие шаблоны, а не просто подставлял заданный код для конкретной программы.

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

Много где говорится, что программы для «Электроники МК-61» занимают не более 105 ячеек памяти. На самом деле, смотря как считать.

Из-за ограниченности памяти у большинства программ константы в регистры вводятся ещё до ввода программы, отдельно и не занимают 105 ячеек, где хранится сама программа. То есть существует часть программы, которая как бы не считается, которая выполняется и результат её выполнения потом используется основной программой.

Например, на приведённом тетрадном развороте справа видно значения, которые надо ввести до ввода программы.

Разворот тетради Александра Долгушина, автора кучи программ для «Электроники МК-61»

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

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

И в «МК-Про», и в «MK-61s» это тоже приходится учитывать. И в первом и во втором проекте пришлось конструировать средства для предвыполнения кода перед основной программой.

В «МК-Про» я сделал особый блок state, где записываются такие конструкции, а в «MK-61s» я просто загружаю в память сначала первый блок и выполняю его, потом, в те же ячейки гружу саму программу.

В моей работе над проектом ретроконсоли «МК-61s» сейчас наступило запланированное затишье: все разумные улучшения сделаны. Иногда я нахожу небольшие ошибки или вижу возможность что-то сделать лучше и вношу соответствующие изменения, но моего активного участия проект уже не требует.

Поэтому высвободившееся внимание я направил на проект «МК-Про» — интерпретатор придуманного мной языка высокого уровня с мощным оптимизатором. Он должен уметь умещать программы разумного объёма в безумные 105 байт, доступных на программируемом калькуляторе «Электроника МК-61».

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

Со временем, у меня сложится такой критерий того насколько нейросеть хорошо решила эту задачу — насколько близко мы приблизились к оптимизированной версии игры «Пещера сокровищ» в варианте Сергея Анварова «Крестики-нолики 4×4» программиста Hs On — монстра оптимизации под эту ретроплатформу.

На настоящий момент разница составляет 34 байта или 25%, я попросил нейросеть нарисовать для наглядности график. Планирую сегодня запустить свежевышедшую на днях сеть «ГПТ-5.6 Сол» в режиме «ультра», посмотрим, продвинется ли она дальше. В режиме «очень высокого» усилия (это уровень, предшествующий режиму «ультра»), она продвинулась на два байта, это много.

Там где значения плюсовые — это исправления каких-то багов оптимизатора

Добавлено позднее: в итоге сеть мне сначала довела почти до 105 байт, а потом откатила часть прогресса, сделанного другими сетями и теперь программа у нас занимает 154 байта. Причина — оптимизации слишком заточены под конкретную программу, что противоречит задаче.

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

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

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

Идея в том, что два целых числа с известными диапазонами можно упаковать в одно число: одно — в целую часть, другое — в дробную. Тогда извлечь их можно операциями нахождения целой части (K [x]) и дробной части (K {x}), причём дробную часть потом часто можно и не домножать: транслятор может заменить всю арифметику с ней так, что всё будет работать ожидаемым образом, но вместо диапазона 0…9 будет использоваться диапазон 0…0,9.

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

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

Вчера я остановился на том, что решатель должен перебирать функции, в том числе тригонометрические: именно они обычно дают самый толковый результат. Но в «МК-61» и в C++ они дают немного разные результаты.

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

Когда я уходил спать, всё работало как часы — нейросеть копалась в ПЗУ калькулятора, сравнивала реализацию с эталоном, разбиралась почему ошибки. Утром я первым делом полез в этот код, чтобы посмотреть что получилось. А там…

А там, как говорят поляки «wygląda jak gówno, a smakuje jeszcze lepiej» — «выглядит как говно, а на вкус ещё лучше». Пятьдесят тысяч строк отвратительного лапшекода, сгенерированного программно из ПЗУ «МК-61».

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

Сегодня наконец закончился процесс переноса кода «МК-Про» на C++. Переписывание заняло около восьми дней, использовались три нейросети. Основной каркас был перенесён с помощью «ГПТ-5.5», часть тестов довольно механически переносилась нейросетью «ГПТ-5.3-Кодекс-Спарк», а последние штрихи вносил и баги чинил «Опус 4.8».

Производительность трансляции улучшилась в среднем в 2,5 раза. Есть один регресс у одной короткой программы, которая выполняются до 50 миллисекунд, но это, скорее всего, погрешность: не исключено, что в этот момент в фоне стартовало что-то тяжёлое.

За восемь дней было переписано 122 тысячи строк, которые превратились в 145,5 тысяч строк на C++.

По моим ощущениям, я должен был перевести с помощью нейросети на Си++ код транслятора языка программирования высокого уровня «МК-Про» для «Электроники МК-61» к вечеру воскресенья. Да, там много сложного кода, но мне казалось, что синтаксически перевести одно в другое, а потом посмотреть на тесты — довольно простая задача для современных нейросетей.

В реальности же пошёл уже шестой день. С некоторыми перерывами, конечно: иногда работа, например, прерывается ночью — сеть ждёт от меня ответа на какой-то вопрос, а я сплю. Так что можно считать, что шестой день работа идёт примерно с семи утра до одиннадцати вечера.

В данном случае мы наблюдаем горе от ума: сеть попроще — GPT-5.3-Codex-Spark — перебрасывает код именно по той схеме, которая была у меня в голове: «айда перепишем, а потом посмотрим на тесты», но у неё быстро кончаются лимиты. А вот ГПТ-5.5 работает более методично: переписывает кусками, основываясь на том, что показывают тесты. Так медленнее, да ещё и тесты гоняются по многу минут, а их много, поэтому всё и идёт туго.

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

Сейчас транслятор «МК-Про» — языка высокого уровня для «Электроники МК-61» — написан на ТайпСкрипте. Я выбрал этот язык по двум причинам: хотелось на него посмотреть, и была идея прикрутить транслятор к эмулятору «МК-61», который работает в браузере.

Но вчера я решил переписать его на Си++. При помощи нейросети, конечно. Производительность ТайпСкрипта стала серьёзным блокером: в процессе трансляции оптимизатор перебирает огромное количество вариантов, чтобы уместить программу в 105 байт, и иногда этот процесс занимает минуты. Надеюсь, перевод на Си++ решит эту проблему.

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

Спустя полтора часа транслировалось уже десять программ и я удивился такой скорости, пошёл читать исходники, а там, то, что на скриншоте — чёртова ленивая нейросеть просто затолкала внутрь кода эталонный результат десяти программ. Офигенное решение.

Язык высокого уровня для программируемого калькулятора «Электроника МК-61», который я начал писать с нейросетью, теперь называется «МК-Про». Надо же его как-то называть.

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

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

На скриншоте видна очередная сессия, которая, как можно заметить длится без перерыва уже более тридцати часов и до конца ещё очень далеко — неделя или около того. Чтобы сеть не прерывалась, я выставил так называемую «цель», её видно на скриншоте.

105 байт памяти, стек и пятнадцать официально доступных регистров вынуждают использовать самые нетривиальные хаки. Их очень много: если начать рассказывать, я буду писать только о них. Самый нетривиальный, как оказалось, — хак с использованием регистра X2. Это недокументированная возможность, поэтому её использование не очень распространено.

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

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

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

Очень интересно разбирать хаки, которые разные люди изобретали, чтобы уместить свои программы в 105 байт памяти калькулятора «Электроники МК-61». Их там действительно просто нереальное количество, они разной сложности, но один из них показателен в своей простоте.

В коде программы «Рембо-III» есть несколько похожих мест (я буду приводить код на языке «МК-Про» для наглядности):

fn lost() {
  halt("ЕГГОГ")
}

fn front_stop() {
    …
    if cells[7] < 0 {
      lost()
    }
    …
}

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

Мой оптимизатор умеет заменять halt("ЕГГОГ") одним опкодом, потому что это «встроенное» в калькулятор слово, но тут он пишет относительно много кода — проверка условия и вызов, тогда как проверку и вывод «еррора» можно объединить в один опкод — F √ или F lg в зависимости от условия.

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

В «Рембо-III» это сокращает программу на четыре байта. Это существенно, когда у доступно так мало памяти.