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.
Когда говорят об архитектуре процессора, внимание часто сосредотачивается на производительности: частоте, количестве ядер, глубине конвейера или наборе аппаратных ускорителей.
Но для Memora8 исходная задача сформулирована иначе.
Это не попытка создать ещё один универсальный процессор с максимально широким набором команд. Memora8 проектируется как простая, обозримая и проверяемая вычислительная архитектура, на которой должна работать операционная система Reganta и модули, написанные на Sekura JS.
Поэтому ISA Memora8 сознательно ограничена.
Здесь небольшой набор команд — не недостаток, а архитектурное решение.
Что такое ISA
ISA, или Instruction Set Architecture, определяет контракт между программным обеспечением и процессором.
Она описывает:
- какие команды понимает процессор;
- как они кодируются;
- какие регистры доступны программе;
- как выполняются вычисления;
- как организованы переходы;
- как программа обращается к памяти;
- как процессор передаёт управление системному коду при исключительных ситуациях.
Программа, компилятор и операционная система работают не непосредственно с транзисторами, конвейером или SRAM. Они работают с этим контрактом.
Именно поэтому стабильность ISA важнее конкретной внутренней реализации процессора.
Реализация Memora8 может развиваться, оптимизироваться и переноситься между симулятором и FPGA, но программная модель должна оставаться понятной и однозначной.
32-битная архитектура с фиксированными инструкциями
Memora8 является 32-битным процессором.
Он использует:
- 32 регистра общего назначения;
- 32-битные значения;
- фиксированную длину инструкции 32 бита;
- 5-битное поле opcode.
Фиксированная длина означает, что каждая инструкция занимает ровно одно 32-битное слово.
Это упрощает:
- выборку инструкций;
- декодирование;
- расчёт следующего PC;
- реализацию конвейера;
- создание ассемблера и компилятора;
- анализ машинного кода;
- формальную проверку процессора.
В архитектуре нет инструкций переменной длины и сложного декодера, который должен сначала определить границы текущей команды.
Процессор всегда знает: следующий последовательный адрес инструкции находится через четыре байта.
Регистровая модель
Memora8 имеет 32 регистра общего назначения:
r0 — r31.
Каждый регистр имеет ширину 32 бита.
Большинство регистров не имеют жёстко закреплённой аппаратной роли. Их назначение определяется ABI, компилятором, Sekura JS и системным программным обеспечением.
Один регистр имеет специальную семантику:
r0 всегда возвращает ноль.
Запись в него синтаксически разрешена, но не изменяет состояние процессора. Поэтому команды вроде:
ADDI r0, r0, 0
могут использоваться как операции без архитектурных побочных эффектов.
Такой подход позволяет сохранить простую и однородную структуру инструкций, не вводя отдельный обязательный opcode для NOP.
Форматы инструкций
Несмотря на фиксированную длину, команды Memora8 используют несколько форматов полей.
R-формат
Используется для операций между регистрами.
Он содержит:
- opcode;
- destination register;
- два регистра-операнда;
- зарезервированное поле.
Зарезервированные 12 бит пока не имеют архитектурной семантики и игнорируются обычными R-инструкциями.
При этом они оставляют пространство для будущего развития архитектуры без изменения базовой длины команды.
I-формат
Используется для операций с непосредственным значением.
Он содержит:
- opcode;
- destination register;
- исходный регистр;
- 17-битное immediate.
OFFSET-формат
Используется условными переходами и JAL.
Он содержит регистр условия или регистр назначения и 22-битное смещение.
M-формат
Используется командами загрузки и сохранения данных.
Он содержит:
- регистр результата или источник данных;
- базовый регистр адреса;
- 17-битное смещение.
Небольшое число форматов делает декодирование предсказуемым. Поля регистров располагаются в одинаковых позициях там, где это возможно.
Арифметические команды
Базовая арифметика представлена командами:
- ADD;
- ADDI;
- SUB.
В ISA нет аппаратных команд умножения, деления и вычисления остатка.
Это принципиальный момент.
Memora8 не пытается перенести в аппаратную ISA каждую возможную операцию языка программирования. Более сложные вычисления могут реализовываться программно, через библиотеки, специализированные модули или отдельные функциональные устройства.
Такое разделение уменьшает сложность CPU и сохраняет его основную модель компактной.
Побитовые операции
ISA содержит стандартный набор логических команд:
- AND;
- ANDI;
- OR;
- ORI;
- XOR;
- XORI.
Этого достаточно для работы с:
- масками;
- флагами;
- битовыми полями;
- адресами;
- системными контрактами;
- результатами сравнения.
Сдвиги представлены командами:
- SHFT;
- SHFTI.
Одна базовая операция сдвига вместо большого семейства специализированных opcode соответствует общей философии Memora8: сохранять ISA небольшой, а конкретную семантику выражать через операнды и программные правила.
Сравнение без глобального регистра флагов
Одна из наиболее характерных особенностей Memora8 — отсутствие отдельного глобального регистра CPU flags.
Команды:
- CMP;
- CMPI
не изменяют скрытое глобальное состояние процессора.
Вместо этого они записывают результат сравнения в обычный регистр назначения.
Результатом является 5-битное слово признаков:
- 0x01 — значения равны;
- 0x02 — первое значение меньше второго при знаковой интерпретации;
- 0x04 — первое значение больше второго при знаковой интерпретации;
- 0x08 — первое значение меньше второго при беззнаковой интерпретации;
- 0x10 — первое значение больше второго при беззнаковой интерпретации.
Перед сравнением оба операнда приводятся к 32 битам.
Например, если программа хочет выполнить переход при знаковом отношении «меньше», она может использовать последовательность:
CMP rC, rA, rB
ANDI rT, rC, 0x02
BNZ rT, target
Сравнение, выбор нужного условия и переход являются отдельными действиями.
Такой подход может потребовать больше команд, чем архитектура с неявными флагами. Но он делает зависимости явными.
Результат сравнения находится в обычном регистре:
- его можно сохранить;
- передать другой функции;
- проверить несколькими масками;
- использовать повторно;
- анализировать как обычное значение.
Для конвейера это также означает отсутствие скрытой зависимости через глобальный регистр флагов.
Связь сравнения с Sekura JS
ISA Memora8 не проектируется отдельно от языка Sekura JS.
В Sekura JS инфиксный оператор:
a ? b
понижается в CMP и возвращает то же 5-битное слово признаков.
Обычные операторы:
- ==;
- !=;
- <;
- <=;
- >;
- >=
строятся поверх сравнения и маскирования результата.
Получается прямое соответствие между семантикой языка и аппаратной командой.
Это важный принцип всей системы:
Sekura JS не должен скрывать полностью другую машинную модель. Его конструкции должны предсказуемо понижаться в небольшой набор операций Memora8.
Управление потоком исполнения
Для условных переходов используются:
- BNZ;
- BEQZ.
Они проверяют обычный регистр:
- BNZ выполняет переход, если значение не равно нулю;
- BEQZ выполняет переход, если значение равно нулю.
Для вызовов и безусловных переходов предусмотрены:
- JAL;
- JALR.
JAL использует относительное смещение и сохраняет адрес возврата в регистр назначения.
JALR вычисляет адрес перехода через регистр и непосредственное значение.
ISA не вводит отдельной аппаратной сущности «функция». На уровне процессора существуют переход, адрес возврата и регистры.
Функции, аргументы, стековые кадры и соглашения о вызовах определяются ABI и компилятором Sekura JS.
Формирование адресов
Для формирования крупных значений и адресов используются:
- LUI;
- AUIPC.
LUI позволяет загружать верхнюю часть значения.
AUIPC формирует значение относительно текущего PC.
Эти команды позволяют строить адреса и константы, которые не помещаются в 17-битное непосредственное поле обычной инструкции.
При этом ISA сохраняет единый 32-битный формат и не вводит инструкции переменной длины для больших констант.
Загрузка и сохранение данных
Работа с памятью выполняется командами:
- LB;
- LBU;
- LH;
- LHU;
- LW;
- SB;
- SH;
- SW.
Поддерживаются операции с:
- байтом;
- половиной слова;
- 32-битным словом.
Команды LB и LH выполняют знаковое расширение.
LBU и LHU загружают беззнаковые значения.
Однако ISA описывает только программно видимую операцию. Фактический доступ к памяти является частью более широкой архитектуры Memora8.
Обычный адрес проходит через:
- виртуальный адрес CPU;
- page window;
- физическую ссылку на страницу;
- банковый арбитр;
- локальную SRAM.
Для доступа к странице требуется эксклюзивное владение ею текущим CPU. В актуальной модели нет режима SHARED_RO: даже чтение выполняется только при наличии ownership.
Таким образом, Load/Store в Memora8 нельзя рассматривать отдельно от модели страниц, MMU-окон и владения памятью.
MTR как явная системная граница
Opcode 0x1F отведён инструкции MTR.
Кроме того, MTR используется как архитектурный механизм передачи управления при ошибках и специальных системных ситуациях.
Причина MTR может обнаруживаться на разных стадиях:
- при выборке инструкции;
- при проверке доступа к данным;
- при отображении страницы;
- при работе с аппаратным ресурсом.
Но архитектурно MTR фиксируется только на стадии COMMIT.
Это означает, что процессор не должен частично изменить состояние, а затем сообщить об ошибке.
Сначала инструкция проходит проверки. Только после этого она либо фиксирует результат, либо фиксирует trap.
Так Memora8 получает точную и предсказуемую модель исключений.
Зарезервированные opcode
Значения:
- 0x1B;
- 0x1C;
- 0x1D;
- 0x1E
помечены как NOTUSE.
Это не случайно свободные номера, которые можно неформально занимать новыми командами.
Они являются частью канонической ISA и зарезервированы для будущих решений.
Такой подход защищает архитектуру от постепенного и несогласованного расширения.
Новая инструкция не должна появляться только потому, что её удобно добавить в текущей реализации. Сначала необходимо определить её смысл, влияние на компилятор, pipeline, верификацию и обратную совместимость.
Как ISA выполняется в pipeline
Memora8 использует пятистадийный конвейер:
IFD → LR → MEM → EX → COMMIT
Где:
- IFD выбирает инструкцию по текущему PC;
- LR декодирует её и читает регистры;
- MEM выполняет работу с памятью и связанные проверки;
- EX выполняет арифметику, сравнение и вычисляет адрес перехода;
- COMMIT фиксирует архитектурный результат.
Конвейер работает:
- в программном порядке;
- с фиксацией не более одной инструкции за такт;
- с изменением архитектурного состояния только в COMMIT.
Если branch или jump изменяет поток исполнения, более молодые инструкции уничтожаются.
Уничтоженная инструкция не имеет права:
- записать регистр;
- выполнить store;
- опубликовать trap.
Это связывает ISA не только с перечнем команд, но и с точной моделью их завершения.
Почему в ISA так мало команд
Ограниченный ISA даёт Memora8 несколько важных свойств.
Простая аппаратная реализация
Меньше команд означает меньше независимых исполнительных путей, специальных состояний и исключений.
Это особенно важно для первой реализации на FPGA.
Предсказуемая компиляция
Компилятору Sekura JS не нужно выбирать между множеством почти одинаковых инструкций.
Каждая языковая операция понижается в небольшое число понятных машинных шаблонов.
Удобство симуляции
Поведение каждой инструкции можно точно воспроизвести в mr8sim.
Чем меньше скрытых эффектов, тем проще сопоставлять результаты симулятора и FPGA.
Формальная проверяемость
Для каждой команды необходимо доказать:
- корректность результата;
- корректность работы с регистрами;
- отсутствие побочных эффектов у killed-инструкций;
- правильную фиксацию исключений;
- соответствие программной и аппаратной модели.
Ограниченный ISA делает такую задачу конечной и обозримой.
Возможность анализа AI
AI значительно легче анализировать архитектуру, если:
- команды имеют фиксированный формат;
- их семантика хранится в явном виде;
- отсутствует большое количество неявного состояния;
- сравнения возвращают обычные значения;
- trap фиксируется в одной определённой точке;
- актуальные решения отделены от устаревших.
Именно здесь ISA Memora8 напрямую связывается с Sekura Noda.
Роль Sekura Noda
ISA — это не только таблица opcode.
Полная архитектурная семантика распределена между несколькими решениями:
- форматы инструкций;
- регистровая модель;
- правила CMP;
- переходы;
- Load/Store;
- MTR;
- pipeline;
- ABI;
- семантика Sekura JS;
- модель памяти;
- системные контракты.
Если хранить всё это только в исходном коде, архитектура постепенно начнёт определяться реализацией.
Тогда симулятор может понимать инструкцию одним образом, RTL — другим, компилятор — третьим, а документация будет описывать уже четвёртую версию.
Sekura Noda используется как центр канонического знания.
Каждое архитектурное решение сохраняется в отдельной связанной статье:
- одна статья определяет ISA;
- другая — форматы;
- третья — регистры;
- отдельные каноны описывают сравнение, переходы, память и trap;
- устаревшие решения получают связь superseded_by;
- связанные статьи образуют граф архитектуры.
Поэтому AI работает не только с текстом запроса и не пытается каждый раз заново угадывать устройство Memora8.
Он получает систему согласованных канонов.
Почему Sekura Noda без AI недостаточно
Сам по себе набор статей ещё не гарантирует целостность архитектуры.
Человек может изменить правило Load/Store и забыть проверить:
- pipeline;
- симулятор;
- MTR;
- MMU;
- компилятор;
- документацию ISA.
AI способен пройти по связанным канонам, найти зависимые решения и показать противоречия.
Например, в базе может сохраниться старая статья, где описан прямой путь к локальной памяти, тогда как актуальная модель требует page windows, physical page reference, банковый арбитр и эксклюзивное владение страницей.
Без статуса superseded такая статья могла бы продолжить влиять на ответы и разработку.
Sekura Noda хранит статус знания и связи между статьями, а AI использует этот граф для проверки целостности.
Почему AI без Sekura Noda также недостаточно
LLM может хорошо объяснить общие принципы ISA, но не знает автоматически, какие именно решения приняты в Memora8 сегодня.
Без канонической базы модель может:
- добавить отсутствующий MUL;
- предположить наличие обычного регистра флагов;
- перепутать порядок стадий pipeline;
- использовать устаревшую модель памяти;
- назвать Memora8 64-битным процессором;
- перенести правила RISC-V или ARM туда, где они не применяются;
- смешать гипотезы и утверждённые решения.
Sekura Noda ограничивает пространство интерпретаций.
AI не должен изобретать архитектуру заново. Он должен читать её актуальное состояние, анализировать связи и помогать развивать систему без потери согласованности.
Рабочий цикл разработки
В разработке Memora8 возникает следующий цикл:
Обсуждение с ChatGPT → канон в Sekura Noda → реализация → анализ → решение
После реализации возможны два результата.
Если код не соответствует канону — исправляется код.
Если в процессе реализации выяснилось, что канон неполон или ошибочен — сначала изменяется архитектурное решение в Sekura Noda, а затем обновляются связанные реализации.
Это не обычная документация после завершения разработки.
Канон участвует в самой разработке.
ISA как граница архитектурной сложности
Memora8 не пытается сделать CPU ответственным за всю вычислительную систему.
CPU выполняет небольшой набор универсальных операций.
Всё остальное может быть вынесено на другие уровни:
- Sekura JS формирует программную семантику;
- ABI определяет взаимодействие модулей;
- Reganta управляет исполнением и памятью;
- FunctionDevice выполняют специализированные задачи;
- Sekura Noda хранит теорию системы;
- AI проверяет согласованность теории и реализации.
Поэтому отсутствие сложной инструкции в ISA не означает отсутствие соответствующей возможности в системе.
Это означает только то, что данная возможность не обязана находиться внутри каждого CPU.
Итог
ISA Memora8 — это компактный 32-битный набор команд с фиксированным кодированием, явными зависимостями и минимальным количеством скрытого состояния.
Её основные свойства:
- 32 регистра по 32 бита;
- фиксированные 32-битные инструкции;
- небольшой набор арифметических и логических операций;
- отсутствие аппаратных MUL, DIV и REM;
- сравнение с записью результата в обычный регистр;
- простые переходы по нулю и ненулю;
- явная работа с адресами;
- ограниченный набор Load/Store;
- единый механизм MTR;
- зарезервированные opcode для контролируемого развития;
- точная фиксация результата только в COMMIT.
Но главное свойство ISA Memora8 заключается не просто в её минимальности.
Она описывается как система связанных архитектурных решений в Sekura Noda.
Благодаря этому процессор, симулятор, Sekura JS, Reganta и инструменты AI могут опираться на одну и ту же теорию.
Именно так небольшой ISA превращается не в ограничение, а в основу архитектуры, которую можно понять целиком, проверить и последовательно развивать.
Share
