Что такое «кириллица как ассемблер» и почему это гипотеза, а не язык
«Кириллица как ассемблер» это предложение построить семантический метаязык, в котором каждая из 33 букв русского алфавита означает одну базовую операцию процессора. Автор идеи сопоставляет «В» с инструкцией PUSH, «Р» с XOR, «К» с RET. Цепочка букв читается как алгоритм: «ВРАК» означает «положить значение на стек, сложить по модулю два, сдвинуть влево, вернуться».
Статус идеи: авторская гипотеза и мнение. Подтверждённой технологии, готового языка или компилятора за ней нет. В материалах по теме отсутствуют и таблица маппинга 33 букв, и «закон удвоения», и «закон взаимного гашения», и пример развёртывания цепочки в поток SIMD-инструкций. Отсутствие подтверждений не опровергает концепцию. Воспроизвести её по имеющимся данным тоже нельзя.
У гипотезы есть теоретические опоры, вариант таблицы маппинга, правила композиции и придуманный автором пример с агрегацией данных. Ниже разбор каждого блока и причины, по которым это пока не работает. Текст носит ознакомительный характер и не служит руководством по написанию кода на кириллице.
Логика гипотезы держится на двух тезисах. Первый: чем ближе форма записи к смыслу операции, тем короче путь от замысла до машинного кода. Второй: 33 буквы уже покрывают базовый набор действий, поэтому буква может работать мнемоникой. Оба тезиса выглядят правдоподобно. Проверяемых следствий из них пока никто не вывел.
Откуда взялась идея: нормальные алгоритмы Маркова и история DSL
Формальная основа, на которую опирается автор, это нормальные алгоритмы Маркова. Андрей Марков ввёл их в 1951 году как модель вычисления на строках: задан алфавит и набор правил подстановки вида «левая часть заменяется правой». Работает первое подходящее правило, процесс идёт до момента, когда применимо хотя бы одно правило. Финальная подстановка останавливает вычисление. По выразительности нормальный алгорифм совпадает с машиной Тьюринга.
Сходство с ассемблером тут поверхностное. Марков переписывает строки знаков и ничего не знает про регистры, флаги, кэш или порядок исполнения. Правило подстановки не имеет семантики операции, оно меняет символы. Гипотеза берёт из этой теории только идею строгой замены и добавляет к ней смысл: буква означает не символ, а действие.
Исторический контекст тоже существует. Предметно-ориентированные языки появлялись каждый раз, когда область требовала собственных обозначений. В промышленной автоматике стандарт МЭК 61131-3 описывает пять языков программирования контроллеров. Два из них, Ladder Diagram (релейные схемы) и Function Block Diagram (функциональные блоки), выглядят как чертёж, а не как текст. Программируемые логические реле поддерживают обычно оба: Ladder Logic читают как электрическую схему, FBD собирают из блоков. Инженер пишет логику в привычных обозначениях, а устройство исполняет её в машинных циклах.
Новизна в кириллическом маппинге неочевидна, потому что семантический слой в ассемблере уже есть. MOV (move), ADD (add), SUB (subtract), JMP (jump), RET (return) это английские слова, сжатые до трёх-четырёх букв и зафиксированные в документации Intel и ARM. Замена латиницы на кириллицу меняет набор символов, а модель описания оставляет прежней.
У любой модели описания есть цена: сложность, производительность, предсказуемость. Разбор о том, как инженерный выбор воспроизводит философские споры показывает это на конструкциях Java, C# и Erlang. У кириллического маппинга такая цена пока не посчитана.
Таблица маппинга: какие буквы каким инструкциям соответствуют
Автор гипотезы называет прямо три соответствия: «В» это PUSH, «Р» это XOR, «К» это RET. Полной таблицы на 33 буквы в описании нет, поэтому ниже вариант, собранный по той же логике: мнемоника выводится из смысла русского слова. Это иллюстрация идеи, а не стандарт и не спецификация.
| Буква | Мнемоника | Как обосновано в гипотезе |
|---|---|---|
| А | SHL | оператор сдвига, двигает цепочку и выравнивание |
| Б | BSWAP | перестановка байтов внутри слова |
| В | PUSH | «вложить»: поместить значение на стек |
| Г | MOV | «груз»: взять данные из памяти в регистр |
| Д | DIV | деление |
| Е | INC | единица, прибавить один |
| Ж | GATHER | «жать, собирать» разрозненные элементы |
| З | ZERO | обнуление, как XOR регистра с самим собой |
| И | AND | логическое «и» |
| Й | NOP | пустая операция, «и краткое» |
| К | RET | «конец»: возврат из подпрограммы |
| Л | LOOP | цикл |
| М | MUL | умножение |
| Н | NEG | отрицание, смена знака |
| О | OR | объединение битов |
| П | POP | снять значение со стека |
| Р | XOR | различие |
| С | CMP | сравнение |
| Т | TEST | проверка битов без изменения операнда |
| У | ADD | увеличение |
| Ф | FMA | слитное умножение со сложением |
| Х | SHR | сдвиг вправо |
| Ц | CMPXCHG | циклическая замена с проверкой |
| Ч | POPCNT | счёт единичных битов |
| Ш | PSHUFB | шафл, перемешивание элементов вектора |
| Щ | PACKUS | упаковка, сжатие разрядности |
| Ъ | LOCK | жёсткая фиксация доступа к памяти |
| Ы | VBROADCAST | размножение одного значения на весь вектор |
| Ь | MASKMOV | мягкая, частичная запись по маске |
| Э | EXTRACT | извлечение элемента из вектора |
| Ю | PUNPCK | сопряжение двух потоков данных |
| Я | CALL | вызов подпрограммы, «ядро» |
Часть соответствий совпадает с настоящими мнемониками ARM и x86, часть нет. MUL, RET, ADD, AND, CMP, NOP существуют в обеих архитектурах почти без изменений. Логическое «или» в ARM называется ORR, а не OR; сдвиги записываются как LSL и LSR, тогда как в x86 это SHL и SHR. Векторный шафл в NEON делается через TBL, аналога PSHUFB по имени нет. Атомарное сравнение с обменом в ARM собирается из пары LDXR и STXR, в x86 есть готовая CMPXCHG. Гипотеза эти расхождения не разбирает.
Запоминание 33 букв с обоснованиями не выглядит проще, чем запоминание 40-50 базовых мнемоник, которые уже описаны в документации. Маппинг неоднозначен: «различие» одинаково тянет на XOR и на CMP, «сложение» на ADD и на FMA. Без формальной грамматики такая таблица остаётся списком ассоциаций.
Правила композиции: закон удвоения, взаимное гашение и буква «А»
Из букв предполагается собирать цепочки, поэтому в гипотезе есть три правила.
Закон удвоения. Повтор буквы усиливает операцию или расширяет операнд. «ВВ» читается как двойной PUSH или как работа с удвоенной разрядностью: положить на стек не 32 бита, а 64. Аналогия в реальном коде тоже есть: в x86 два вызова push занимают больше стека, а векторные операции обрабатывают за инструкцию 128, 256 или 512 бит.
Закон взаимного гашения. Некоторые пары букв аннигилируют, как одинаковые подстановки в нормальном алгоритме Маркова или как XOR регистра с самим собой. «РР» обнуляет значение, «В» рядом с «П» даёт пустое действие: положили на стек и сразу сняли. В реальном ассемблере симметричные пары действительно бессмысленны, и компиляторы их вырезают. В гипотезе это правило сформулировано словами, без списка гасящих пар.
Буква «А» как оператор сдвига. «А» не выполняет работу над данными, она двигает саму цепочку: меняет выравнивание, порядок применения или позицию элемента в векторе. Из-за этого «А» читается как служебный знак, похожий по роли на префиксы повторения в x86 или на модификатор сдвига в операндах ARM.
Композиция выглядит так: «ВРАК» это PUSH, XOR, сдвиг, RET, то есть положить, сложить по модулю два, сдвинуть, вернуться. Ни одно из трёх правил не имеет строгого определения, и это главная проблема. «ВВ» можно прочитать двумя способами, а «РР» способно и обнулить данные, и означать два разных XOR подряд. Формальной грамматики, которая снимает такую двусмысленность, в гипотезе нет.
Пример: агрегация данных с подавлением шума через SIMD без ветвлений
Прикладная часть гипотезы это задача агрегации с подавлением шума. Есть массив измерений, часть значений испорчена выбросами, нужно посчитать устойчивую сумму или среднее. Автор предлагает записать алгоритм семантической цепочкой на кириллице, которая разворачивается в поток SIMD-инструкций без условных переходов.
Почему отсутствие ветвлений важно, объясняется арифметикой процессора. Ветка с непредсказуемым условием стоит десятки тактов на промахе предсказателя, а векторное исполнение обрабатывает 4, 8 или 16 значений за одну инструкцию. Проверка условия заменяется маской и выбором значения: min, max, blend, maskmove. Так устроены библиотеки обработки сигналов и статистики.
Цепочка в гипотезе выглядит примерно так: «Г» загружает данные, «Ш» перемешивает элементы под нужный порядок, «Р» обнуляет аккумулятор, «С» сравнивает с порогом, «А» двигает маску. Развёртка такой цепочки в реальные инструкции могла бы выглядеть так. Код ниже это иллюстрация, а не рабочий пример и не результат тестов.
// псевдокод: во что могла бы развернуться цепочка
// Г: загрузка вектора
__m128 v = _mm_loadu_ps(src);
// С: сравнение с порогом дает маску, ветка не нужна
__m128 mask = _mm_cmpgt_ps(v, hi);
// ограничение сверху и снизу вместо if
v = _mm_min_ps(v, hi);
v = _mm_max_ps(v, lo);
// Р: накопление суммы
acc = _mm_add_ps(acc, v);
Инструкции здесь настоящие: SSE и AVX в x86, NEON в ARM дают минимум, максимум, сравнение с маской и векторное сложение. Для байтовых данных в x86 есть PSADBW, которая складывает модули разностей восьми байт за раз, а в ARM похожую работу делает VABA. Маскированные операции в AVX-512 и SVE позволяют вообще не заводить отдельную ветку на «грязные» элементы.
Чего в примере нет, так это конкретного маппинга. Цепочка букв останавливается на уровне «загрузить, сравнить, сдвинуть», а какой именно опкод выбрать для «Ш» и как разложить «А» на выравнивание, гипотеза не говорит. Без этого шага пример остаётся схемой, а не трансляцией.
Возможные перспективы: нейросимволическое взаимодействие и смена ролей
Финальная часть гипотезы описывает смену ролей: человек становится компилятором смыслов, машина интерпретатором. В терминах AI это близко к нейросимволическому подходу, где нейросеть работает с нечёткими смыслами, а символьный слой отвечает за строгие правила и исполнение. Разделение выглядит логичным: генерация смысла требует гибкости, а исполнение требует детерминизма.
Частично такая схема уже работает. LLM пишут код, компилятор проверяет синтаксис, тесты отсеивают ошибки, а человек отвечает за постановку задачи. Про то, где генерация ускоряет разработку, а где создаёт технический долг, есть отдельный разбор вайб-кодинга и спора об эффективности LLM.
Опасность в том, что символьный слой в кириллической гипотезе нечем проверить. Нейросеть может сгенерировать красивую цепочку букв, у которой не будет однозначной семантики. Насколько ошибочными бывают внутренние рассуждения модели, показывает разбор эксперимента catmind-1.2b: точность на бенчмарке упала с 75,6% до 24,3%, когда модель вместо ответа генерировала рассуждение не по задаче. Если цепочки мнемоник будет писать LLM, нужен независимый проверяльщик, а его в гипотезе нет.
Ограничения и критика: почему это пока не работает
- Нет формальной спецификации. Отсутствуют алфавит правил, грамматика цепочек и таблица переходов. Без них две реализации одной идеи дадут разный результат.
- Нет транслятора. Компилятора, ассемблера или хотя бы интерпретатора, который превращает кириллическую цепочку в машинный код, не существует.
- Нет тестов и эталонов. Не с чем сравнить ни корректность, ни производительность. Любое утверждение о скорости остаётся словами.
- Масштаб не сходится. 33 буквы покрывают 33 понятия, а в x86-64 несколько сотен базовых мнемоник, и с учётом векторных расширений и вариантов операндов счёт идёт на тысячи кодировок. Придётся либо повторять буквы, либо вводить модификаторы.
- Модель процессора шире мнемоник. Регистры, флаги, порядок исполнения, задержки, выравнивание, модель памяти и когерентность кэшей в гипотезе не описаны. Ассемблер это не только имена операций, это ещё операнды, директивы и секции.
- Мнемоники уже семантичны. MOV, ADD и RET несут смысл с 1970-х, и замена латинских слов на русские буквы модель описания не меняет.
- Порог входа не падает. Выучить 33 буквы, три закона и правила их сочетания тяжелее, чем запомнить около пятидесяти мнемоник, по которым есть документация и тысячи примеров.
Отсутствие подтверждений в материалах не делает идею ложной. Ранние языки и нотации тоже сначала существовали как текст, а не как инструмент. Проблема в другом: гипотеза пока не сформулирована так, чтобы её можно было проверить и опровергнуть.
Итог: стоит ли следить за развитием темы
«Кириллица как ассемблер» остаётся авторской гипотезой. Как упражнение в семантическом программировании она любопытна: заставляет думать о том, где проходит граница между смыслом и опкодом и что именно теряется при переводе идеи в инструкции. Как рабочий инструмент она не готова: нет спецификации, транслятора, тестов и сравнения с существующими языками.
Чтобы тема стала проверяемой, нужны четыре вещи. Формальная грамматика с однозначной семантикой каждой буквы и правила сочетаний. Эталонный транслятор, пусть на сотню строк Python, который выдаёт настоящий ассемблер через GNU as, NASM или Keystone. Набор задач, где результат сравнивают с кодом обычного компилятора по количеству инструкций и времени работы. Публичные тесты, которые может повторить любой человек.
Проверить идею в домашних условиях тоже реально. Возьмите 10 базовых операций (MOV, ADD, SUB, XOR, AND, SHL, CMP, JMP, CALL, RET), сопоставьте им буквы, напишите простейший транслятор цепочки в текст ассемблера, соберите его и посмотрите на дизассемблированный результат. Если цепочка из четырёх букв разворачивается в осмысленный код и работает быстрее ветвящегося варианта, это уже интересный результат. Если нет, гипотеза получит то, чего ей сейчас не хватает: проверку.