The post has been translated automatically. Original language: Russian
Sekura JS is a low—level programming language of the Sekura ecosystem. It is being developed as part of its own R&D stack, which includes the Memora8 processor architecture, the Reganta micro-operating system, a compiler, a simulator, and the Noda engineering knowledge system.
Sekura JS is closer to system programming: explicit types, explicit memory, predictable compilation, modules, ABI, and direct connection to the machine model.
Why did Sekura JS appear?
When developing your own processor architecture, the question quickly arises: what language should you write system code in?
You can use an existing language: C, C++, Rust, Zig, or another system programming tool. This is a reasonable path if the architecture is already stable and you need to integrate into the existing ecosystem.
But in the Sekura project, the task is different.
CPU Memora8, Micro OS Reganta and Sekura JS are developing simultaneously. The processor architecture affects the language. The language affects the compiler backend. The operating system affects the ABI and the modular model.
Therefore, Sekura JS appeared not as a replacement for existing languages, but as part of a full-stack study: from the source code to the executable module and its own processor architecture.
A low-level language with no hidden runtime
Sekura JS does not try to be a dynamic scripting language. It does not aim to build a complex managed runtime, automatic memory management, or a rich reflective model.
On the contrary, the language makes visible those things that are important in system programming.:
- data layout;
- pointers;
- The size of the types;
- cost of operations;
- ABI;
- module structure;
- the relationship of code with architecture.
It's a language that doesn't hide the machine, but helps you work with it in a more organized way.
Types, memory, and layout
Sekura JS uses a compact model based on a 32-bit architecture. The language has integer types of 8, 16, and 32 bits, signed and unsigned variants, structures, arrays, and pointers.
For the language, it is important not only that the variable has a type, but also how the data is placed in memory. The structure in Sekura JS is not just a group of fields, but a layout description. The order of the fields, the size of the values, and the way they are accessed should be predictable.
This is important because Sekura JS is designed for an environment where the language, compiler, and processor architecture are directly connected.
Functions and modules
Functions in Sekura JS are the basic unit of behavior. They have parameters, a return type, and a body of execution. But for a system language, functions are not just a convenient syntax. For the compiler backend, the function sets the entry point, call convention, stack operation, and result return.
A separate place is occupied by the modular model. A module in Sekura JS is not just a code file. The runtime module has its own layout, preview, import and export tables, entry path, functions, data section, and ABI contract. This makes the module an architectural unit. It can be assembled, described, loaded, and linked to other modules through a clear interface.
Toolchain and compilation artifacts
Sekura JS does not hide the compilation process behind a single binary file. After compilation, several artifacts are created.:
- .sasm — assembler-text;
- .sdef — description of the placement and symbols;
- .sobj — binary object of the module;
- .smod is the description of the export ABI of the module.
This approach makes the toolchain transparent. Each stage can be analyzed separately: the source code, the assembler representation, the object module, and the ABI contract. This is especially important for an R&D project, where the architecture is still developing, and the compiler is not only a tool, but also a way to test architectural solutions.
Why is the assembler rendered separately?
In Sekura JS assembler, the representation exists as a separate .sasm artifact. Therefore, inline assembler is not part of the language. This solution keeps a clean boundary between the language and the assembler layer. Sekura JS is responsible for types, functions, structures, modules, and predictable code generation. The assembler pass remains a separate stage of the toolchain. This makes it easier to analyze the compilation result, maintain the backend, and avoid mixing two different levels of program description.
Memora8 as a native architecture
Sekura JS's native direction is compilation for Memora8. Memora8 is an exploratory 32—bit architecture built around a page-oriented memory model and simple hardware contracts. Sekura JS takes this environment into account. Explicit types, memory management, modularity, ABI, and a predictable path from the source text to the executable object are important for it. In this sense, Sekura JS is not a language “for everything at all". Its first task is to be a system language for its own architecture.
Why might LLVM be needed?
At the same time, Sekura JS has another possible direction of development — LLVM IR generation. The idea here is not to replace your own toolchain. On the contrary, the native path under Memora8 remains an important part of the project. LLVM can become an additional backend that will allow you to run Sekura JS on existing architectures: x86, ARM, RISC-V or WASM. Then the model becomes a double:
- Sekura JS → native Sekura toolchain → Memora8;
- Sekura JS → LLVM IR → existing processors.
- This is important not only technically, but also practically.
While there is no physical Memora8, the LLVM direction can allow people to try the language on ordinary computers. At the same time, the modular Sekura JS model, ABI ideas, and the structure of runtime modules can remain part of the language. LLVM is responsible for generating machine code, but is not required to replace the Sekura architectural model.
What Sekura JS is exploring
Sekura JS is not an attempt to compete with C, Rust, Zig or JavaScript. The project explores another issue.: what should a low-level language be like if it is designed simultaneously with a processor, an operating system, a compiler backend, and a modular runtime?
Usually, the language is adapted to an existing architecture. In Sekura, everything happens differently: architecture, language, OS, and toolchain evolve together. When Memora8 changes, the backend changes. When the ABI is clarified, the modular model changes. As Reganta evolves, the requirements for the system code change. This is what makes Sekura JS interesting as an R&D project.
Current status
Sekura JS remains a research language within the Sekura ecosystem. Its main properties are:
- explicit types;
- explicit memory;
- structures and layout;
- pointers;
- modules;
- imports and exports;
- predictable codegen;
- own compile artifacts;
- connection to Memora8;
- potential referral to LLVM IR.
The main goal of the project is not to create another universal programming language, but to build a language that works honestly in a low—level environment and develops along with the architecture for which it is being created.
Sekura JS is a language where JS stands for Jupiter Soft, not JavaScript. His main idea is to explore his own system stack: from the source code to the processor.
Sekura JS — это низкоуровневый язык программирования экосистемы Sekura. Он разрабатывается как часть собственного R&D-стека, куда входят процессорная архитектура Memora8, микро-операционная система Reganta, компилятор, симулятор и система инженерных знаний Noda.
Sekura JS ближе к системному программированию: явные типы, явная память, предсказуемая компиляция, модули, ABI и прямая связь с машинной моделью.
Почему появился Sekura JS
При разработке собственной процессорной архитектуры быстро возникает вопрос: на каком языке писать системный код?
Можно взять существующий язык: C, C++, Rust, Zig или другой инструмент системного программирования. Это разумный путь, если архитектура уже стабильна и нужно встроиться в существующую экосистему.
Но в проекте Sekura задача другая.
CPU Memora8, Micro OS Reganta и Sekura JS развиваются одновременно. Процессорная архитектура влияет на язык. Язык влияет на compiler backend. Операционная система влияет на ABI и модульную модель.
Поэтому Sekura JS появился не как замена существующим языкам, а как часть исследования полного стека: от исходного кода до исполняемого модуля и собственной процессорной архитектуры.
Низкоуровневый язык без скрытого runtime
Sekura JS не пытается быть динамическим скриптовым языком. В нём нет цели построить сложный managed runtime, автоматическое управление памятью или богатую reflective-модель.
Наоборот, язык делает видимыми те вещи, которые важны в системном программировании:
- layout данных;
- указатели;
- размер типов;
- стоимость операций;
- ABI;
- структуру модуля;
- связь кода с архитектурой.
Это язык, который не скрывает машину, а помогает работать с ней более организованно.
Типы, память и layout
Sekura JS использует компактную типовую модель, ориентированную на 32-битную архитектуру. В языке есть целочисленные типы размером 8, 16 и 32 бита, знаковые и беззнаковые варианты, структуры, массивы и указатели.
Для языка важно не только то, что переменная имеет тип, но и то, как данные размещаются в памяти. Структура в Sekura JS — это не просто группа полей, а описание layout. Порядок полей, размер значений и способ доступа к ним должны быть предсказуемыми.
Это важно потому, что Sekura JS проектируется для среды, где язык, компилятор и процессорная архитектура связаны напрямую.
Функции и модули
Функции в Sekura JS являются базовой единицей поведения. Они имеют параметры, возвращаемый тип и тело выполнения. Но для системного языка функции — это не только удобный синтаксис. Для compiler backend функция задаёт точку входа, соглашение вызова, работу со стеком и возврат результата.
Отдельное место занимает модульная модель. Модуль в Sekura JS — это не просто файл с кодом. Runtime-модуль имеет собственный layout, preamble, таблицы импортов и экспортов, entry path, функции, data section и ABI-контракт. Это делает модуль архитектурной единицей. Он может быть собран, описан, загружен и связан с другими модулями через понятную поверхность взаимодействия.
Toolchain и артефакты компиляции
Sekura JS не скрывает процесс компиляции за одним бинарным файлом. После компиляции создаются несколько артефактов:
- .sasm — assembler-текст;
- .sdef — описание размещения и символов;
- .sobj — бинарный объект модуля;
- .smod — описание export ABI модуля.
Такой подход делает toolchain прозрачным. Каждый этап можно анализировать отдельно: исходный код, assembler-представление, объектный модуль и ABI-контракт. Это особенно важно для R&D-проекта, где архитектура ещё развивается, а компилятор является не только инструментом, но и способом проверки архитектурных решений.
Почему assembler вынесен отдельно
В Sekura JS assembler-представление существует как отдельный .sasm-артефакт. Поэтому inline assembler не является частью языка. Это решение сохраняет чистую границу между языком и assembler-уровнем. Sekura JS отвечает за типы, функции, структуры, модули и генерацию предсказуемого кода. Assembler-проход остаётся отдельным этапом toolchain. Так проще анализировать результат компиляции, поддерживать backend и не смешивать два разных уровня описания программы.
Memora8 как родная архитектура
Родное направление Sekura JS — компиляция под Memora8. Memora8 — это исследовательская 32-битная архитектура, построенная вокруг page-oriented модели памяти и простых аппаратных контрактов. Sekura JS учитывает эту среду. Для него важны явные типы, работа с памятью, модульность, ABI и предсказуемый путь от исходного текста до исполняемого объекта. В этом смысле Sekura JS не является языком “вообще для всего”. Его первая задача — быть системным языком для собственной архитектуры.
Зачем может понадобиться LLVM
При этом у Sekura JS есть ещё одно возможное направление развития — генерация LLVM IR. Идея здесь не в том, чтобы заменить собственный toolchain. Напротив, родной путь под Memora8 остаётся важной частью проекта. LLVM может стать дополнительным backend, который позволит запускать Sekura JS на существующих архитектурах: x86, ARM, RISC-V или WASM. Тогда модель становится двойной:
- Sekura JS → родной Sekura toolchain → Memora8;
- Sekura JS → LLVM IR → существующие процессоры.
- Это важно не только технически, но и практически.
Пока физического Memora8 нет, LLVM-направление может позволить людям пробовать язык на обычных компьютерах. При этом модульная модель Sekura JS, ABI-идеи и структура runtime-модулей могут оставаться частью языка. LLVM отвечает за генерацию машинного кода, но не обязан заменять архитектурную модель Sekura.
Что исследует Sekura JS
Sekura JS — это не попытка конкурировать с C, Rust, Zig или JavaScript. Проект исследует другой вопрос: каким должен быть низкоуровневый язык, если он проектируется одновременно с процессором, операционной системой, compiler backend и модульным runtime?
Обычно язык адаптируют под уже существующую архитектуру. В Sekura всё происходит иначе: архитектура, язык, OS и toolchain развиваются вместе. Когда меняется Memora8, меняется backend. Когда уточняется ABI, меняется модульная модель. Когда развивается Reganta, меняются требования к системному коду. Именно это делает Sekura JS интересным как R&D-проект.
Текущее состояние
Sekura JS остаётся исследовательским языком внутри экосистемы Sekura. Его главные свойства:
- явные типы;
- явная память;
- структуры и layout;
- указатели;
- модули;
- imports и exports;
- предсказуемый codegen;
- собственные compile artifacts;
- связь с Memora8;
- потенциальное направление в LLVM IR.
Главная цель проекта — не создать ещё один универсальный язык программирования, а построить язык, который честно работает в низкоуровневой среде и развивается вместе с архитектурой, для которой он создаётся.
Sekura JS — это язык, где JS означает Jupiter Soft, а не JavaScript. Его основная идея — исследование собственного системного стека: от исходного кода до процессора.
Share
