The post has been translated automatically. Original language: Russian
Method Zettelkasten appeared long before modern language models.
His idea was simple: knowledge should exist not as a set of documents, but as a network of linked notes.
It turned out to be incredibly effective for humans.
But with the advent of AI, the situation has changed.
Today, many people perceive the knowledge base as a place to store documents.
In my opinion, this is an outdated approach.
Why doesn't Sekura Noda exist without AI
Can I ask a provocative question?:
Do I need Sekura Noda without AI?
Probably not.
If knowledge is intended only for a person, documents, Wiki or classic Zettelkasten are enough.
Sekura Noda was created for a different purpose.
Its main user is not only a human, but also a language model.
Therefore, knowledge should be organized in such a way that AI can correctly understand the architecture of the project, determine the current rules and not mix old solutions with new ones.
But AI doesn't work well without Sekura Noda either.
You can connect ChatGPT to thousands of documents.
He will read them.
He will draw conclusions.
But he doesn't know:
- which solution is valid?;
- which article is outdated;
- what was replaced;
- what knowledge is required?;
- where the architecture boundary lies.
As a result, AI begins to build responses to a mixture of old and new solutions.
The problem is not with the model.
The problem lies in the organization of knowledge.
Modern Zettelkasten
Sekura Noda retains the main principle of Zettelkasten:
knowledge exists as a network of related articles.
But it adds something that didn't exist before.:
- canonical knowledge;
- versions;
- statuses;
- connections between solutions;
- choosing the context for AI;
- the opportunity to develop knowledge along with the project.
In fact, Sekura Noda is a modern Zettelkasten, built specifically for the era of large language models.
Reinforcing cycle
The most interesting part begins when the AI becomes a participant in the development.
During the design of Memora8 and the Reganta operating system, we constantly use ChatGPT to discuss architectural solutions.
But correspondence does not automatically become part of knowledge.
After verification, the solution turns into the Sekura Noda canon.
In the next discussion, ChatGPT is already working not only with the code, but also with the accumulated knowledge of the project.
It turns out a cycle of self-reinforcement:
ChatGPT helps to create knowledge.
Sekura Noda retains proven knowledge.
Proven knowledge makes the following dialogue with ChatGPT much more accurate.
This is no longer a knowledge base.
A regular knowledge base stores information.
Sekura Noda helps AI think in the context of a project.
That's why I consider it a modern development of the Zettelkasten idea.
A card box once enhanced a person.
Sekura Noda enhances the collaboration between humans and artificial intelligence.
Individually, they lose most of their value.
Together they form a system that not only accumulates knowledge, but also helps to create new ones.
Когда говорят об оптимизации языка программирования, обычно имеют в виду ускорение программы или уменьшение размера машинного кода.
Для системного языка этого недостаточно.
Оптимизация не должна случайно изменить ABI, разрушить модульный контракт или сделать поведение компилятора непредсказуемым. Особенно когда язык разрабатывается одновременно с собственной операционной системой Reganta и процессорной архитектурой Memora8.
Поэтому оптимизация Sekura JS строится не как один агрессивный механизм, а как последовательность контролируемых уровней:
O0 → O1 → O2 → O3
Отдельно существует экспериментальный профиль OTM.
Каждый уровень отвечает за свой класс преобразований и сохраняет определённые архитектурные гарантии.
O0: прозрачная генерация
O0 — базовый режим без оптимизирующих проходов.
Его задача заключается не в скорости, а в прозрачности.
Сгенерированный ассемблерный код должен максимально прямо соответствовать исходной программе и работе генератора кода.
Такой режим нужен для:
- отладки frontend и backend компилятора;
- анализа полученного .sasm;
- проверки соглашений о вызовах;
- поиска ошибок генерации;
- сравнения исходной конструкции с итоговыми инструкциями.
Для Sekura JS это особенно важно.
Язык развивается вместе с Memora8, поэтому сначала необходимо проверить правильность генерации для целевой архитектуры и только затем применять преобразования.
O0 служит контрольной точкой, относительно которой можно анализировать работу остальных уровней.
O1: устранение локальной избыточности
O1 выполняет безопасные локальные преобразования ассемблерного кода.
Оптимизатор рассматривает соседние инструкции и заменяет избыточные последовательности более короткими.
Например, после сохранения значения во frame компилятор может сразу же загрузить его обратно в другой регистр. Если между этими операциями значение не могло измениться, повторное чтение памяти заменяется передачей значения между регистрами.
Такой подход уменьшает количество обращений к памяти и исполняемых инструкций.
Кроме того, O1 может:
- удалять лишние переходы;
- упрощать короткие условные ветвления;
- сокращать очевидно избыточные последовательности;
- устранять отдельные повторные загрузки.
При этом O1 не анализирует всю программу, не перестраивает функции и не меняет ABI.
Его главная задача:
уменьшить количество инструкций без изменения структуры программы и её внешнего поведения.
Это классическая локальная peephole-оптимизация, но встроенная в архитектурные ограничения Sekura JS.
O2: удаление недостижимых функций
O2 работает уже не только с соседними инструкциями.
Он анализирует связи между функциями и строит достижимую часть графа вызовов.
Корневыми точками считаются:
- __entry;
- main;
- экспортируемые функции.
Далее компилятор определяет, какие функции могут быть вызваны из этих точек.
Если функция не является экспортируемой и недостижима из корневого кода, она удаляется из итогового модуля.
Это уменьшает:
- размер .sasm;
- размер .sobj;
- объём памяти, занимаемый кодом;
- время загрузки модуля.
Главный принцип O2:
не создавать машинный код для функций, которые программа никогда не выполнит.
Но здесь есть важное ограничение.
Нельзя просто удалить все функции, которые не вызываются внутри текущего исходного файла. Экспортируемая функция может использоваться другим runtime-модулем после загрузки.
Поэтому экспортируемая поверхность является частью контракта и сохраняется независимо от внутренних вызовов.
O2 не выполняет inline и не меняет ABI. Межмодульные вызовы продолжают работать по прежним правилам.
O3: распределение значений по регистрам
O3 оптимизирует уже не количество функций, а стоимость исполнения оставшегося кода.
На этом уровне компилятор отслеживает время жизни виртуальных значений и распределяет их по физическим регистрам Memora8.
Пока значение требуется для дальнейших вычислений, компилятор старается держать его в регистре, а не сохранять во frame функции.
Когда значение больше не используется, освободившийся регистр можно передать следующему результату.
Особое внимание уделяется вызовам функций.
Если значение должно сохраниться после выполнения JAL или JALR, его необходимо разместить в callee-saved-регистре либо сохранить так, чтобы оно пережило границу вызова.
O3 уменьшает количество:
- spill-операций;
- загрузок из памяти;
- записей во frame;
- сохранений и восстановлений регистров;
- временных перемещений данных.
Этот уровень особенно полезен для функций с большим количеством локальных вычислений и вложенных вызовов.
Если O2 уменьшает объём программы, удаляя недостижимые функции, то O3 ускоряет оставшийся код за счёт более эффективного использования регистров.
Главная цель O3:
сократить стоимость работы с регистрами и памятью во время исполнения.
Почему O3 выделен отдельно
Локальная оптимизация инструкций и распределение регистров решают разные задачи.
O1 рассматривает уже сформированные небольшие последовательности ассемблерного кода.
O3 должен знать время жизни значений, границы вызовов и доступность физических регистров.
Это уже не просто замена одной инструкции другой. Это управление ресурсами процессора во время генерации кода.
Поэтому register-aware codegen выделен в отдельный уровень.
Так проще проверять его корректность и понимать, какое именно преобразование повлияло на результат.
OTM: пространство для максимальной оптимизации
Кроме O0–O3, в Sekura JS существует профиль OTM — Optimization Test Maximum.
Он зарезервирован для максимального безопасного уплотнения статически собранного модуля и его внутреннего графа вызовов.
В текущем стабильном состоянии OTM использует проверенный optimization pipeline O2.
Это означает, что отдельное имя и режим уже существуют, но дополнительные агрессивные преобразования пока не включены в стабильный контракт.
OTM выделен отдельно намеренно.
Уровни O0, O1, O2 и O3 должны сохранять понятное и предсказуемое значение. Экспериментальные преобразования можно развивать в OTM, не меняя задним числом смысл стабильных уровней.
Если эксперимент подтверждает безопасность и пользу новой оптимизации, позже она может получить собственный формальный контракт.
Оптимизация и compile artifacts
Sekura JS формирует несколько отдельных артефактов:
- .sasm — текстовое ассемблерное представление;
- .sdef — определения модуля;
- .sobj — собранный объект;
- .smod — данные runtime-модуля, когда они необходимы.
Оптимизатор не может рассматривать .sasm как изолированный набор инструкций.
Он должен учитывать:
- точку входа;
- __entry;
- main;
- экспортируемые функции;
- таблицу функций;
- runtime-вызовы;
- модульный ABI;
- зависимости библиотек;
- способы загрузки и связывания модулей.
Например, функция может казаться неиспользуемой внутри одного .sasm, но быть доступной через экспортируемую таблицу runtime-модуля.
Поэтому правильность оптимизации определяется не только локальным кодом, но и всей моделью исполнения Sekura JS.
Почему нет цели оптимизировать любой ценой
Некоторые компиляторы стремятся применить как можно больше преобразований.
В Sekura JS приоритет другой:
оптимизация допустима только тогда, когда её границы определены и проверены.
Агрессивный inline, перестройка межмодульных вызовов или изменение экспортируемой поверхности могут дать прирост производительности, но одновременно нарушить архитектурные контракты Reganta.
Поэтому оптимизация вводится постепенно.
Сначала формулируется правило.
Затем определяется, какие объекты оно может изменять.
После этого проверяются ABI, модульная модель и поведение runtime.
И только затем преобразование становится частью стабильного уровня оптимизации.
Как в разработке участвует Sekura Noda
Архитектурные ограничения оптимизатора невозможно надёжно хранить только в исходном коде.
Из реализации можно увидеть, что делает конкретный pass.
Но код не всегда объясняет:
- почему O1 ограничен локальными преобразованиями;
- почему export-функции являются корнями O2;
- почему O2 не выполняет inline;
- какие значения должны переживать JAL и JALR;
- почему O3 обязан учитывать callee-saved-регистры;
- зачем OTM отделён от стабильных уровней.
Эти решения фиксируются в Sekura Noda как канонические знания проекта.
В отдельных статьях описываются:
- уровни оптимизации;
- конкретные преобразования O1;
- правила достижимости O2;
- register-aware codegen O3;
- назначение OTM;
- модель модулей;
- compile artifacts;
- runtime-layout;
- соглашения о вызовах.
В результате оптимизатор существует не как набор разрозненных технических решений, а как часть общей теории языка.
Sekura Noda не просто документирует код
Обычная документация часто пишется после реализации.
В таком подходе код является первичным, а статья лишь пересказывает его текущее состояние.
В разработке Sekura JS Sekura Noda играет другую роль.
Канон определяет, какое поведение считается архитектурно допустимым.
Например, перед реализацией удаления функций необходимо ответить на вопросы:
- Что является корнем графа вызовов?
- Может ли функция вызываться извне?
- Должна ли экспортируемая функция сохраняться без внутренних ссылок?
- Допустимо ли изменить её идентификатор?
- Не сломается ли .smod после оптимизации?
Только после фиксации этих правил можно корректно реализовать O2.
То же относится к O3.
Недостаточно просто написать allocator регистров. Сначала нужно определить:
- какие регистры являются временными;
- какие сохраняются через вызов;
- где проходят границы времени жизни;
- когда необходим spill;
- какие значения обязаны пережить JAL или JALR.
Sekura Noda хранит эти правила в форме, доступной человеку и AI.
Как ChatGPT и Sekura Noda усиливают разработку
Практический цикл разработки выглядит так:
Вопрос → обсуждение с ChatGPT → проверка канонов → анализ кода → реализация → тестирование → обновление Sekura Noda
ChatGPT помогает:
- анализировать возможные оптимизации;
- искать пограничные случаи;
- сравнивать реализацию с архитектурой;
- находить противоречия между статьями;
- проверять влияние изменений на ABI;
- формулировать правила в понятной форме.
Но результат обсуждения не становится каноном автоматически.
Гипотеза сначала проверяется в коде и тестах.
После этого подтверждённое решение фиксируется в Sekura Noda.
В следующем цикле ChatGPT получает уже не только исходный код и историю переписки, а действующую архитектурную модель.
Получается усиливающий процесс:
ChatGPT помогает развивать оптимизатор.
Sekura Noda сохраняет проверенные решения.
Сохранённые решения делают следующий анализ ChatGPT точнее.
Почему Sekura Noda без AI не работает
Sekura Noda не создавалась как обычная Wiki или архив статей.
Без AI она могла бы хранить каноны, связи и версии, но оставалась бы в основном пассивным хранилищем.
Её основная ценность появляется, когда языковая модель использует знания как рабочий контекст.
AI может:
- собрать связанные статьи по конкретной задаче;
- сопоставить разные части архитектуры;
- проверить новое решение относительно действующих канонов;
- найти устаревшее или противоречивое знание;
- объяснить последствия изменения;
- помочь обновить теорию вместе с реализацией.
Поэтому Sekura Noda без AI не выполняет своё полное назначение.
Но верно и обратное.
AI без Sekura Noda вынужден каждый раз заново анализировать код, переписки и документы. Он может смешивать старые и новые решения, не знать, какой контракт является действующим, и строить убедительные выводы на неверном контексте.
Sekura Noda и ChatGPT проектируются как две части одного инженерного метода.
ChatGPT предоставляет анализ.
Sekura Noda предоставляет память, связи и канон.
Человек проверяет решение и определяет, какое знание становится действующим.
Пример развития канона
Общая ранняя статья об уровнях оптимизации Sekura JS описывала O0, O1 и O2.
Позже появился отдельный принятый канон O3, определяющий распределение значений по физическим регистрам.
Если ориентироваться только на старую обзорную статью, можно ошибочно решить, что O3 отсутствует.
Но поиск по связанным канонам Sekura Noda обнаруживает более новое архитектурное знание.
Это практический пример того, зачем системе нужны:
- отдельные статьи;
- связи;
- категории;
- поиск;
- статусы;
- развитие канонов;
- AI, способный собрать целостную картину.
Знание проекта не всегда находится в одном документе.
Sekura Noda позволяет восстановить его из сети действующих архитектурных решений.
Оптимизация как часть общей архитектуры
Уровни оптимизации Sekura JS можно кратко представить так:
O0 — показывает код без оптимизации.
O1 — удаляет локальную избыточность инструкций.
O2 — удаляет недостижимые функции.
O3 — эффективнее распределяет значения по физическим регистрам.
OTM — оставляет пространство для будущих максимальных безопасных преобразований.
Каждый следующий уровень работает с более широким контекстом:
инструкция → локальная последовательность → граф функций → время жизни значений и регистры
Но ни один уровень не должен разрушать модульные контракты языка.
Итог
Оптимизация Sekura JS развивается постепенно и контролируемо.
O0 обеспечивает прозрачность генерации.
O1 сокращает локальные избыточные последовательности.
O2 удаляет функции, недостижимые из точек входа и экспортируемой поверхности.
O3 снижает количество spill-операций и обращений к памяти за счёт управления временем жизни значений и физическими регистрами.
OTM создаёт отдельное пространство для будущих экспериментальных оптимизаций.
Sekura Noda хранит архитектурные причины, ограничения и связи между этими уровнями.
ChatGPT использует накопленные знания для анализа новых решений.
Человек проверяет результат и принимает канон.
Благодаря этому оптимизация развивается не как набор случайных улучшений компилятора, а как согласованная часть языка Sekura JS, процессора Memora8 и операционной системы Reganta.
Share
