Table of Contents

Ubytec Project Introduction

Goals and Design Philosophy

Ubytec is envisioned as a universal intermediate language and bytecode system designed for broad interoperability across programming languages and platforms. Its core philosophy is to provide a structured, extensible representation of program logic that is both human-readable and machine-executable. Ubytec’s design emphasizes a fully-defined Abstract Syntax Tree (AST) model and a rich opcode set, enabling high-level language constructs (like functions, classes, loops) to be represented alongside low-level operations in a single unified format. Each element of the Ubytec language can be compiled into either textual form or a bytecode representation, reflecting the project’s dual focus on readability and executability. This approach ensures that tools (compilers, interpreters, debuggers) can handle Ubytec ASTs consistently across different environments and language versions. In practice, Ubytec serves as an intermediate layer – language authors can target Ubytec as a compilation target, and toolchain developers can build backends (or interpreters) for it, knowing the specification covers everything from high-level semantics down to concrete opcodes. Crucially, the Ubytec AST carries extensive metadata about the source program (down to original source code tokens and positions) to maintain transparency through the compilation pipeline. The overarching goal is universality and clarity: any program’s logic can be encoded in Ubytec’s portable format, allowing it to be compiled or interpreted on any platform that supports the Ubytec runtime model.

Ubytec’s design philosophy also stresses extensibility and future-proofing. The opcode space is designed to be open-ended – standard operations are assigned numeric opcodes 0 through 254, and the value 255 is reserved to denote an extended opcode that includes an extension group identifier. This mechanism allows the introduction of new instruction sets or domain-specific opcodes without altering the core 1-byte opcode space. In other words, Ubytec can evolve by defining new ExtensionGroup and ExtendedOpCode values under the umbrella opcode 255, accommodating future languages and paradigms. This forward-looking design is balanced with formal rigor: the project provides a strict JSON Schema for Ubytec ASTs to ensure that any extensions or new features remain structurally consistent and validate against a known specification. By combining a language-agnostic AST with a machine-level opcode set, Ubytec’s philosophy is to bridge the gap between high-level programming concepts and low-level execution, all while remaining unambiguous and tool-friendly.

Architecture Overview

Ubytec Architecture is composed of several layers, moving from human-readable source through to executable code, with a well-defined runtime model at its core. The architecture can be described in terms of: (1) the runtime execution model (how Ubytec code behaves at run-time), (2) the compiler toolchain pipeline (how source is transformed into Ubytec and machine code), (3) the AST schema format (the structural representation of code), and (4) development tooling such as VS Code integration.

Runtime Model

Ubytec employs a structured, stack-based execution model with block-scoped control flow. At runtime, a Ubytec program behaves like a virtual stack machine: instructions operate on an implicit stack, and high-level control constructs (like loops and conditionals) are realized through structured blocks and jumps. The core opcode set includes familiar stack-machine operations (e.g. PUSH, POP, DUP for stack manipulation) and structured control flow markers (BLOCK, LOOP, IF, ELSE, END, etc.), as well as arithmetic and logic instructions. Notably, Ubytec’s control flow is block-structured rather than relying on arbitrary jumps; for example, BLOCK/END demarcate structured regions, and looping constructs (LOOP, WHILE, etc.) use these blocks and explicit opcodes rather than raw jump addresses. Internally, during execution, Ubytec’s model pushes and pops values on a stack and uses generated labels to manage control flow for these structured opcodes. This structured approach is similar in spirit to WebAssembly’s block/loop design (though Ubytec extends it with higher-level constructs like classes and functions, as discussed below).

Currently, the Ubytec interpreter implementation actually compiles Ubytec code to native machine code (x86_64 NASM assembly) rather than executing via a custom VM. The runtime model therefore is realized in terms of an actual 64-bit process: the compiler emits standard assembly sections for data, bss, and text, and produces an entry point that sets up and calls the Ubytec Main function. For example, a compiled Ubytec program’s assembly will include directives like section .data for static data (and .bss for zero-initialized data) followed by a section .text with code. The generated code declares a global _start symbol as the program entry. At _start, the runtime sets up a stack frame (if needed) and invokes the user-defined Main function by name, then exits cleanly via an OS syscall. In the emitted assembly, structured Ubytec constructs correspond to labeled blocks and structured jumps. The stack machine semantics of Ubytec are mapped onto the actual CPU stack and registers: for instance, a Ubytec PUSH might compile to a sequence of instructions that move a constant into a register and push it, and arithmetic opcodes (e.g. ADD) become the corresponding ALU operations popping operands from and pushing results to the stack. Indeed, the current compiler backend uses a “naive stack on the CPU stack itself” strategy – values are pushed and popped to the machine stack, and each structured opcode (BLOCK, IF, LOOP, etc.) generates appropriate labels and jumps in the assembly. This direct translation approach makes the Ubytec runtime model efficient on real hardware, at the cost of being initially target-specific (Linux x86_64). The architecture, however, is not fundamentally tied to x86: the abstract stack machine and opcode design could be retargeted to other architectures or to a virtual machine interpreter in the future. The presence of a well-defined opcode set and an AST that “encapsulates everything needed to compile or interpret” a piece of code suggests that a bytecode VM for Ubytec is conceptually feasible as a future runtime, using the same semantics defined now.

A Ubytec program is organized around the concept of a Module – analogous to a compilation unit or program module. The module can contain declarations of functions (func), actions, global and local contexts (for global/static and local variable declarations), user-defined types (classes, structs, records, interfaces, enums), and nested sub-modules. At runtime, these high-level constructs are lowered to concrete behaviors: for example, a class with methods would be compiled into appropriate data structures in the data section (for vtables, etc., if needed) and the methods into functions in the text section. The Ubytec runtime model currently does not define a garbage-collected heap or automatic memory management within the bytecode itself – memory management is manual or left to the host environment, aside from the stack usage. There are placeholder opcodes for memory access (LOAD/STORE), but these are marked as optional and are not fully utilized in the current implementation. In summary, the Ubytec runtime model is that of a statically compiled, stack-based program that, when executed, behaves like a conventional program launched at _start and running to termination, but structured internally by Ubytec’s own instruction set and semantics.

Compiler Toolchain

The Ubytec project provides a full compiler toolchain that takes source code in Ubytec’s high-level syntax and produces both machine code and structured outputs. The toolchain comprises the following stages:

  1. Lexical Analysis – Source code (UTF-8 text) is first tokenized into a stream of SyntaxToken objects. Ubytec uses a TextMate grammar for its lexical specification, which is shared with the VS Code extension. The interpreter loads the official Ubytec grammar (from the vscode-ubytec repository) at startup and uses it to perform syntax highlighting and token classification. In the compiler pipeline, a component called the LexicalAnalyst initializes this grammar and tokenizes the source, producing tokens annotated with their source text, type, and position. This means the lexing stage is precisely aligned with the editor’s understanding of the language – keywords, operators, identifiers, etc., are recognized according to the same .tmLanguage specification used for highlighting.

  2. Parsing to AST – The sequence of tokens is then parsed by the HighLevel Parser into Ubytec’s high-level AST. Ubytec’s syntax has a C/Java-style flavor for declarations (e.g., module (name:"X", version:"Y") { ... } and inner blocks denoted by braces) combined with structured assembly for the code bodies (e.g., sequences of opcodes like block, if, loop, etc., possibly annotated with types). The HighLevelParser builds a Module AST node representing the entire module, which contains child nodes for each declared entity (functions, types, etc.). During this process, the parser enforces language rules and collects any syntax or semantic errors. Rather than aborting on the first error, the parser is designed to gracefully collect parse errors and continue, so that multiple issues can be reported in one pass. The output of parsing is a Module AST (if parsing succeeds) along with a list of any parse warnings/errors.

  3. Compilation to Bytecode/Assembly – Once the Module AST is constructed (and validated), the next stage is to compile this high-level AST into low-level form. Each AST node in Ubytec implements the IUbytecEntity interface which defines a Compile(CompilationScopes scopes) method. The compiler essentially traverses the AST and emits textual assembly code for each entity by calling these Compile methods. For example, the Module.Compile implementation emits data section definitions for global variables, then text section code for each function, action, and type in the module. It manages a stack of CompilationScope objects to handle nested blocks and control-flow contexts during code generation (each scope provides context like start/end labels for a block, etc.). As it descends into, say, a function node, it will emit the function prologue label, then compile each instruction inside (which could include nested blocks, handled via scope stack), and so on, finally emitting an epilogue or return sequence. The compiler automatically inserts the necessary boilerplate for program startup and termination. As shown in the generated assembly, after all user code is emitted, the compiler adds an _start entry that calls the Main function (if present) and then performs an OS syscall to exit the process. The end result of this stage is a block of x86-64 assembly code (NASM syntax) which represents the entire program logic. This assembly can then be assembled and linked using standard tools to produce an executable. (In the future, this stage could target other architectures or a virtual machine bytecode – the source is structured enough to support alternate backends – but currently x86-64 NASM is the only backend.)

  4. Output Artifacts – The final stage produces various output artifacts for the compiled program. The primary output is the NASM assembly text, which the tool writes to an .ubc.nasm file. Additionally, the compiler serializes the full AST of the module into a JSON file (.ubc.json), conforming to the Ubytec schema, and also produces a UTF-64 encoded version of that JSON. UTF-64 is a custom encoding (inspired by Iain Merrick’s concept) that packs the JSON text into a safe, compact ASCII string. The UTF-64 output (with .utf64 extension) represents the same AST data in a dense form, suitable for embedding in environments where raw JSON might be inconvenient. Together, the JSON and UTF-64 files capture the exact structured AST of the program after compilation, including all metadata (such as GUIDs for each node, source code references, etc.). These artifacts are extremely useful for tooling: for instance, a language server or analysis tool can load the .ubc.json to inspect the AST, or the .utf64 string could be used to transmit the AST over a network or command-line. The JSON AST can be validated against the Ubytec schema to ensure the compiler’s output is correct. In summary, after compilation, a developer has: an assembly file ready to assemble into machine code, and structured data (AST in JSON) that can feed into documentation, debugging, or further compilation stages. All of these steps – lexing, parsing, codegen, output – are automated in the ubytec-interpreter tool, which serves as an end-to-end compiler driver, so compiling a Ubytec source module is a one-command process.

AST Schema Format

A cornerstone of Ubytec’s architecture is the Extended Ubytec AST Schema, a formal JSON Schema that defines the structure of Ubytec’s Abstract Syntax Tree format. This schema is fundamental for ensuring that any tool or component that produces or consumes Ubytec ASTs adheres to the same structure and conventions. At a high level, the Ubytec AST (in JSON form) is organized as follows:

  • A top-level RootSentence object, which contains the entire program tree. This RootSentence has lists of child nodes and/or nested sentences representing the program’s structure (for example, the module-level code is a Sentence containing Nodes for each top-level statement or declaration). It serves as the container for everything in one compilation unit.

  • Top-level Metadata accompanying the RootSentence, which includes information about the AST as a whole, such as a unique GUID for the tree, the source text encoding, and a langver field indicating the Ubytec language version or dialect used. This allows the AST to be self-descriptive – tools can check the langver to handle backward compatibility or features.

  • SyntaxSentence entries, which represent blocks or scopes of code (analogous to a compound statement or a code block in curly braces). A SyntaxSentence can contain an array of Nodes (each a SyntaxNode for a statement or operation) and its own array of nested Sentences (for inner blocks). Each Sentence also carries metadata including a GUID and a type string (e.g., "loop", "if", "block") identifying what kind of block it is. This hierarchical structure mirrors the nested nature of code.

  • SyntaxNode structures, which are the fundamental units corresponding to individual operations, declarations, or expressions. Every SyntaxNode has an Operation field (describing the opcode or language construct it represents), optional Children (nested SyntaxNodes, if this operation encloses a sub-structure), optional Tokens (a list of source code token snippets corresponding to this node), and Metadata. For example, a SyntaxNode might represent a single instruction like an ADD operation, with no children and maybe one token (the text "add" from source). Or it could represent a higher-level construct like a function declaration operation, with Children nodes for the function body, and tokens for the keyword and name.

  • Operation objects describe the actual operation or opcode of a SyntaxNode. An Operation has an OpCode field, which can be either a number (0–254) for standard opcodes or an object {OpCode: 255, ExtensionGroup: X, ExtendedOpCode: Y} for extended opcodes. (Internally, the schema also allows an optional $type field in Operation for a human-readable name of the opcode, like "ADD" or "IF", primarily for clarity; the real execution semantics are determined by the numeric OpCode.) Additional fields in Operation include:

    • BlockType: for block-beginning operations (like function entry or block entry), this can specify a type or return type identifier (e.g., BlockType might hold an integer representing a data type if the block has a typed result, similar to how WebAssembly blocks have types).
    • Condition: used in conditional opcodes (IF, WHILE) to store the parsed condition expression (left side, operator, right side).
    • LabelIDxs: a list of label indices for branch operations, allowing reference to named loop labels or switch-case labels.
    • Variables: an array detailing any variables declared by this operation (for example, a function’s Operation may list its parameters or local variables here, including type info and default values). These subfields ensure that a single Operation node encapsulates all information needed for code generation or interpretation of that construct. For instance, an IF node’s Operation will include its Condition object, so the runtime or compiler knows exactly what condition to evaluate.

  • SyntaxToken objects, which appear in the AST mainly inside the Tokens arrays of SyntaxNodes. Each SyntaxToken captures the lexical details of a piece of source text: it has the original Source string (exact text), the source Line (or full line) from which it came, and the Row (line number) and Column (character position) in the source file. It also has a Scopes array which lists the TextMate scope names for that token (e.g., "keyword.control.flow.ubytec" for an if keyword, or "constant.numeric.int.ubytec" for an integer literal). These scope names correspond exactly to the VS Code grammar and are even enumerated in the schema for validation (the schema includes an enum of all allowed scope strings). The presence of tokens with their scopes in the AST is invaluable for tooling: it provides a direct mapping from structured AST elements back to the raw source text, enabling features like precise error reporting, syntax highlighting of AST-derived code, or round-trip source generation. Essentially, the AST is lossless with respect to the original source, down to every token and position, which aligns with Ubytec’s philosophy of making the compiled form transparent and debuggable.

  • Metadata objects at various levels: RootMetadata for the whole AST (with fields like guid, encoding, langver), SentenceMetadata for each sentence (with at least a GUID and a type label), NodeMetadata for each node (with GUIDs and possibly a NASM code snippet or other backreferences), etc.. These metadata ensure uniqueness (GUIDs provide unique IDs for nodes and blocks) and can carry additional information like a snippet of compiled assembly associated with a node (for debugging or tracing).

The Ubytec JSON Schema (which follows JSON Schema Draft 2020-12) rigorously defines all these components – their types, required fields, and allowed values. This schema is included in the schema repository and can be used to validate any Ubytec AST JSON. For example, after the compiler outputs output.module.ubc.json, one can run a JSON Schema validator to ensure the AST conforms to the spec. The schema also serves as documentation for the AST structure. It covers not only the current shape of Ubytec but is explicitly designed to accommodate future growth. For instance, as mentioned, the OpCode definition allows extended opcodes via an object form. The schema documentation encourages extending the schema with new properties or opcode definitions when new language features are added, implying a controlled evolution of the format. Backwards compatibility can be managed by the langver metadata – if a future change is not backward compatible, the langver string would change, and tools can detect that.

In summary, the Ubytec AST schema format provides a canonical, self-describing representation of Ubytec code. It ensures that the structural and semantic information of the code is preserved in a language-agnostic way. Developers and language authors can rely on this schema to generate Ubytec ASTs from other languages or to consume Ubytec ASTs for analysis. Because it is JSON, the AST can be easily generated or processed in many environments, and because it’s rigorously specified, independent implementations can interoperate (for example, a third-party compiler could emit Ubytec AST JSON and the official interpreter could consume it, or vice versa, with confidence). The Extended Ubytec Schema is what elevates Ubytec from just another bytecode into a full-fledged IR specification: it captures high-level intent (through structured nodes and rich metadata) while still mapping down to low-level operations (through the opcode fields).

VS Code Support and Tooling

Ubytec comes with first-class Visual Studio Code support to aid developers working with Ubytec code or integrating it into their toolchains. The project’s repository vscode-ubytec contains a VS Code extension that provides syntax highlighting, theming, and potentially other editor features for Ubytec. The extension defines a TextMate grammar (ubytec.tmLanguage.json) which enumerates Ubytec’s lexical patterns and scope names. This is the same grammar used by the compiler’s LexicalAnalyst, meaning there is a single source of truth for the language’s tokens. As a result, code highlighted in VS Code will have scopes identical to the tokens recorded in the AST’s Scopes arrays, ensuring consistency between what developers see and what the compiler processes. For example, keywords like module, func, if, etc., are all tagged with scopes (such as keyword.control.ubytec or keyword.control.flow.ubytec), and these appear in both the editor’s coloring and the AST. A GitHub Actions workflow in the Ubytec schema repo even automatically synchronizes the grammar and schema: it fetches the latest ubytec.tmLanguage.json from the vscode extension and updates the schema’s list of valid scopes (ensuring any new token categories are reflected). This tight integration means the language definition remains unified across the compiler, the schema, and the editor.

In addition to the grammar, the VS Code extension provides a custom theme called “Ubytec Future Thunder”. This theme is tailored for Ubytec’s token scopes, giving a distinct color palette to Ubytec code elements for better readability. The interpreter references this theme in its default settings (it can fetch the theme JSON from the extension repository). For instance, opcode keywords might be colored differently from type names or constants, as defined in the theme. By bundling a theme, the project ensures that Ubytec code is not only recognized by VS Code but also presented in an optimal way (especially important for a new language where generic color themes may not highlight important distinctions).

While syntax highlighting is fully supported, other aspects of VS Code integration are still basic at this stage. The extension defines the language grammar and theme, and likely basic editor settings (file extensions, comment patterns, etc.). Deeper IDE features like IntelliSense, auto-completion, or a language server are not yet implemented, but the groundwork is laid for them: the existence of the JSON AST means a language server could be built to provide rich analysis, and the compiler’s ability to report errors with line info means the editor can underline errors in Ubytec code. As development continues, we may see integration such as on-the-fly compilation or AST visualization in the editor.

For now, developers authoring Ubytec code can install the VS Code extension to get proper syntax coloring and file recognition. They can write Ubytec modules in VS Code, see keywords, types, and strings highlighted according to the Future Thunder theme, and rely on the extension’s grammar for bracket matching and basic editing support. The consistency between the VS Code extension and the compiler (in terms of grammar) is a notable strength: for example, if the language is updated to add a new keyword or operator, adding it to the TextMate grammar and schema will automatically propagate to both the editor experience and the compiler’s tokenizer. This reduces the chance of editor/compiler discrepancies.

In summary, the Ubytec project is equipped with a modern editing environment integration from the start. The VS Code support reflects Ubytec’s emphasis on developer experience – even though Ubytec is an IR, it has a human-readable form meant to be written and understood by developers (especially language developers). By providing tooling for editing and viewing Ubytec code, the project invites experimentation and adoption. Language and toolchain authors can easily inspect the Ubytec output of their compilers in VS Code, using the highlighting to understand the structure, and even manually write Ubytec code for testing. This aligns with the project’s goal of being transparent and accessible, as opposed to a “black box” binary blob bytecode.

Historical Context and Development Status

The Ubytec project is relatively young and under active development. Its origins lie in the idea of creating a “universal bytecode” that could serve as a common IR for multiple programming languages, combining the strengths of stack-based virtual machines (like the JVM or WebAssembly) with a flexible, high-level schema. Early in development, Ubytec’s focus was primarily on defining a core instruction set and getting a basic compilation working. The initial implementation of the compiler was a straightforward translator that mapped opcodes to a byte array and then to x86 assembly. In fact, an early component named DeprecatedCompiler still exists in the codebase, containing a simple mapping of mnemonic to opcode byte and routines to generate x86-64 assembly from a linear bytecode stream. This component is marked [Obsolete] and has been superseded by the more robust AST-based compiler pipeline. The shift from that initial approach to the current architecture marks a significant evolution in the project: the team recognized the need for a richer representation (AST) to handle complex language features and ensure extensibility, and thus expanded the design to include the high-level parser, context-sensitive compilation scopes, and the JSON schema. This can be seen as Ubytec transitioning from a “proof of concept bytecode” to a full-fledged language infrastructure.

Throughout its development, Ubytec has steadily incorporated more high-level language features. For instance, support for structured types (structs, classes, interfaces, etc.) and module scoping was added, allowing Ubytec to represent object-oriented and modular code, not just flat sequences of instructions. The presence of constructs like global { } and local { } blocks in the module syntax (for global and local declarations) and of composite entities like Property (perhaps for global mutable storage) or Action (which might represent asynchronous functions or special routines) indicates the project’s intent to handle a wide range of programming paradigms. These features are in various stages of implementation: the parser recognizes and builds AST nodes for them, and the compiler will emit code for many (for example, it does output data and bss sections for globals and generates code for class methods, as seen in the Module.Compile logic). However, some features are still work-in-progress or stubbed out. For example, the module header’s requires field is parsed and stored (it captures a list of required module names, hinting at future module linking), but as of now there is no link step that actually imports other modules – multi-module linking is a planned feature. Similarly, the opcode set contains placeholders like POWER, QUANTUM, VECTOR, and THREADING (visible in the enumeration of token scopes and reserved keywords), even though concrete semantics for these domains have not yet been implemented. These appear to be reserved for future expansion (e.g., keyword.quantum.ubytec suggests the team foresees quantum computing instructions, and keyword.threading.ubytec implies planned concurrency or threading primitives). At present, these opcodes are not generated by the compiler; they are simply part of the taxonomy, likely to stake out the design space for later development.

The current development status of Ubytec is that of a functional prototype or alpha. The core components – tokenizer, parser, AST schema, and x86_64 code generator – are in place and working for a subset of the language (basic arithmetic, control flow, function calls, and simple data definitions have been demonstrated). The project’s repository includes examples (for instance, a demo module is embedded in the Program.cs driver with a nested loop and condition structure) which successfully compile to NASM and produce the expected output. The fact that the project can output a running 64-bit binary is a significant milestone; it shows that Ubytec is not just theoretical but capable of producing real executables. However, many advanced features remain unimplemented or partially implemented. For example, exception handling (keyword.exception.ubytec) is likely planned but not yet functional, memory management beyond static arrays isn’t implemented (the LOAD/STORE opcodes exist in the table but the semantics might be rudimentary), and the type system is still evolving (the schema defines a structure for BlockType and type modifiers like IsNullable and IsArray on types, suggesting future robust type checking). The language version is currently labeled “1.0” in metadata, but this should be understood as a 1.0 of the schema format rather than a final feature-complete release – development is ongoing.

Ubytec’s repositories (interpreter, schema, VSCode extension) are under active iteration by a small team. Commits in the last year have included major refactoring (e.g., introducing the AST compiler and deprecating old code) and additions to the schema (the schema file is titled "Extended Ubytec Schema", indicating it has been recently extended or is an extended version of an earlier schema). There is also evidence of continuous integration setup (workflows for schema-grammar sync, Codacy code quality checks, etc.), which shows a maturing project infrastructure. No formal release has been tagged yet, and API stability is not guaranteed at this stage. Prospective adopters (like language authors who want to compile to Ubytec) should be prepared for possible changes in the spec as the project solidifies various features.

In summary, Ubytec’s current status is pre-release but progressing: the fundamental pieces are working (you can write a simple Ubytec module and compile it to a working program), and the design space for future capabilities is laid out, though not all of it is realized. The project has reached a point where external contributors or early adopters can experiment with it – for example, by writing a tiny language that targets Ubytec AST or by writing Ubytec code directly – but it is not yet at a 1.0 production-ready stage in terms of completeness or optimization. The emphasis so far has been on getting the architecture right (especially the AST schema and the overall pipeline), with performance optimizations and comprehensive library support likely to come later.

Future Roadmap

The roadmap for Ubytec, as inferred from the project repositories and design, is quite ambitious. The developers have clearly built Ubytec with future expansion in mind, and several planned directions are evident:

  • Expanding the Instruction Set: Many reserved opcode categories in the grammar and schema hint at upcoming features. For instance, Ubytec defines token scopes for keyword.audio, keyword.ml (machine learning), keyword.quantum, keyword.threading, keyword.security, keyword.syscall, keyword.system, keyword.vector, and more. This indicates an intention to support domain-specific instructions or libraries (e.g., audio processing, parallel computing, quantum instructions, vector/SIMD operations, system calls) that go beyond the current basic set. These would likely be implemented as extended opcodes (using the ExtensionGroup mechanism) when introduced. The schema’s extended opcode design can accommodate 256 groups with 256 ops each, so the roadmap likely includes defining some of those groups for specific domains. For example, a “quantum” ExtensionGroup might be defined with opcodes for qubit manipulation, or a “vector” group for SIMD vector arithmetic. The presence of keyword.ml.ubytec suggests even high-level constructs for machine learning (perhaps tensor operations or embedded DSL support) could be added. These additions will make Ubytec more attractive as a compilation target for specialized languages (a scientific computing language could use the vector opcodes, a quantum language could use the quantum opcodes, etc.). The roadmap likely schedules these enhancements once the core language is stable.

  • Optimization and Performance: So far, the focus has been on correctness and completeness of the representation. As Ubytec matures, the compiler will need optimization passes. Currently, the code generation is straightforward (almost 1:1 translation of AST to assembly). Future work will include optimizations such as constant folding, dead-code elimination, and register allocation improvements (right now the assembly uses a naïve stack model which is not optimal). Additionally, a future JIT or interpreter might be considered for scenarios where compiling to native code is less desirable (for example, a Ubytec VM for dynamic execution or sandboxing). The AST is rich enough to support advanced optimizations and analyses; implementing those is on the roadmap once the baseline functionality is done.

  • Multi-Module Linking and Libraries: Ubytec’s module system includes a requires clause and supports sub-modules, pointing toward a future in which Ubytec programs can be composed of multiple modules (possibly compiled separately and linked together). The roadmap likely includes developing a linker or a module resolution system. For example, if one Ubytec module requires another, the build system would compile both and then link their data and text sections, resolving references. The schema could be extended to represent imported functions or external references in the AST. Eventually, we might see a Ubytec standard library emerge – a set of modules providing common routines (math, I/O, etc.) that can be required by programs. At the current stage, this is not implemented, but the syntax and structure in place will facilitate it.

  • Stronger Type System and Verification: The schema contains elements for types (e.g., in Operation.BlockType and in variable definitions, there are type codes and flags for nullable or array types). In the future, Ubytec may introduce a more explicit type system, possibly similar to WebAssembly’s (which has a limited set of value types and block signatures) but potentially extendable (since Ubytec also has classes and interfaces, a richer type system is implied). A likely roadmap item is to implement a type checker or verifier for Ubytec modules – ensuring at compile-time or load-time that the Ubytec bytecode is type-safe (operands match operation expectations, jumps target correct block types, etc.). This would make Ubytec safer for use as a portable code format. The groundwork for this is the metadata on variables and BlockTypes in the AST. In the near future, the compiler might start enforcing type rules (currently, it’s somewhat permissive or assumes correct input).

  • Improved Tooling and Language Server: Given the emphasis on making Ubytec accessible to developers, a logical step is creating a Language Server Protocol (LSP) implementation for Ubytec. This would provide auto-completion, on-the-fly error checking, go-to-definition, etc., in editors. The existing VS Code extension could be enhanced to use such a language server. The existence of the JSON AST makes it feasible: the language server could compile Ubytec code to an AST in the background and use that for rich analysis (for example, to list all functions, or to find references of a variable). The roadmap might include editor integrations beyond VS Code (perhaps JetBrains plugin or others), but VS Code is the primary focus.

  • Cross-Language and Backend Implementations: As “universal” implies, the project may seek to have multiple frontends and backends. The current C# implementation is both a frontend (it parses Ubytec text) and a backend (it generates x86). In the future, we might see alternative frontends – for example, a compiler from a subset of C or Python into Ubytec IR, to demonstrate Ubytec’s universality. We might also see alternative backends – a WebAssembly backend for Ubytec (so that Ubytec code can run in browsers by translating Ubytec ops to WebAssembly) or a JVM bytecode backend. While not explicitly stated, these ideas align with the project’s ethos and could be long-term goals. In particular, a Ubytec Virtual Machine could be created to execute Ubytec bytecode directly, making it truly platform-independent. The current design has all the pieces for a VM (a defined instruction set, a schema to validate programs, etc.), so writing an interpreter for the Ubytec bytecode is straightforward. The team has hinted at interpretation by ensuring each AST node holds what’s needed to interpret it. This could become a reality if performance demands or portability needs drive the development of an official Ubytec VM.

  • Stabilization and Versioning: Over the next phases, the project will likely work on stabilizing the spec. The langver field in the AST metadata (e.g., "langver": "1.0.x") suggests that versioning is on the radar. We can expect a formal 1.0 release of the Ubytec spec once the core features (basic opcodes, functions, module linking, etc.) are fully implemented and tested. After that, changes would be introduced in a backward-compatible way when possible, or the langver would be bumped for breaking changes. The Extended Schema may also be split into a base schema and extensions for optional features, depending on how the project manages growth (for instance, not every environment may support “quantum” opcodes, so those could be in an extension group that tools can choose to support or not).

In conclusion, the roadmap of Ubytec points toward it becoming a comprehensive universal bytecode ecosystem. Near-term, expect completion of partially implemented features (module linking, exception handling, memory ops) and improvements in reliability and tooling. Mid-term, watch for new opcode groups enabling whole new categories of computation (parallelism, system-level programming, domain-specific accelerations). Long-term, Ubytec aims to be a stable target for many source languages and a deployable format on many platforms. The project is careful to distinguish between what is implemented now and what is anticipated: all forward-looking features are grounded in placeholders or notes in the current repos (nothing is purely speculative – the design documents and schema already account for them). As the repositories state, new features will be added alongside schema updates to incorporate them, ensuring that the vision of Ubytec as a truly universal, extensible bytecode is realized step by step with a solid specification backing it.

Sources:

  • Ubytec Interpreter & Schema Repositories (master branches) – Design comments, source code and JSON schema on the language syntax, the module structure, and the opcode listings, as well as the Ubytec specification documents. Contributors and interested readers are encouraged to join the project – see the community and contribution guidelines to get involved. Ubytec’s vision is ambitious: unify program execution across all devices. This introduction has covered the basics of the system and its components; the rest of the documentation will delve deeper into how to write Ubytec code, the detailed semantics of the bytecode, and how the ecosystem will expand in the future.
Edit this page