NOL is an experimental native systems programming language designed around deterministic execution, explicit resource control, predictable memory behavior, low runtime overhead, and direct interaction with modern computer architectures.
NOL is being developed as both a standalone systems language and the native programming foundation of the broader NOS operating-system architecture.
Status: Experimental / under active development. The compiler architecture, language specification, self-hosting chain, and native targets are still evolving.
Most modern programming languages trade some degree of architectural control for abstraction, runtime services, dynamic allocation, garbage collection, or complex execution environments.
NOL explores a different direction.
The project asks a simple question:
How much software complexity can be removed when the language, compiler, memory model, ABI, and operating system are designed together?
NOL is therefore not intended to be another syntax layer over an existing runtime.
Its long-term goal is a vertically integrated native computing model in which source code can map to machine execution with as little hidden machinery as possible.
NOL development is guided by several core principles:
- Native execution
- Deterministic memory behavior
- Explicit ownership and resource control
- No mandatory garbage collector
- No hidden allocation in performance-critical paths
- Static and pre-reserved memory regions where practical
- Controlled arena/region leasing instead of conventional heap dependence
- Predictable data layout
- Low-overhead abstractions
- Minimal runtime dependency
- Compiler reproducibility
- Self-hosting as a primary milestone
- Architecture-aware compilation
- Zero-copy-oriented system design
- Security through reduced implicit state and explicit boundaries
These are architectural objectives. Individual features remain subject to implementation, testing, benchmarking, and revision.
Memory architecture is one of the central ideas behind NOL.
NOL is not being designed around a traditional model in which arbitrary parts of a program continuously request and release memory through a general-purpose heap.
Instead, the project favors:
Pre-reserved memory
│
▼
Deterministic regions / arenas
│
▼
Explicit ownership
│
▼
Controlled leasing / sub-allocation
│
▼
Predictable release or reuse
The objective is to preserve the performance and predictability benefits of static memory while still allowing controlled runtime flexibility.
This does not mean that every NOL program must have a completely fixed memory footprint.
It means that dynamic behavior should not automatically imply an uncontrolled general-purpose heap, hidden allocation, or mandatory garbage collection.
The NOL compiler is being developed toward a fully native bootstrap chain:
NOL Source
│
▼
Lexer / Streaming Front End
│
▼
Parser
│
▼
NOL Intermediate Representation
│
▼
Lowering / Optimization
│
▼
Native Emitter
│
▼
Executable Machine Code
A major project milestone is self-hosting: compiling the NOL compiler using NOL itself.
The intended validation chain is:
Bootstrap Compiler
│
▼
Stage 1
│
▼
Stage 2
│
▼
Stage 3
The strongest reproducibility target is:
Stage 2 == Stage 3
at the byte level.
When achieved reproducibly, this provides a powerful fixed-point check that recompiling the compiler no longer changes the resulting compiler binary.
Cryptographic hashes such as SHA-256 can then be used as a convenient identity check:
SHA256(Stage2) == SHA256(Stage3)
This target should not be interpreted as completed until it is demonstrated by reproducible builds and published verification results.
NOL is designed as a native language rather than as a language requiring a virtual machine as its primary execution environment.
Current and planned architecture work includes:
x86-64 Primary native target
ARM64 Planned / under architectural development
Bare Metal Long-term target
UEFI/EFI NOS bootstrap target
Additional architectures may be considered after the language and compiler bootstrap chain are stable.
NOL is part of a larger systems architecture.
┌─────────────┐
│ Applications│
└──────┬──────┘
│
┌──────▼──────┐
│ NOL │
│ Native Lang │
└──────┬──────┘
│
┌──────▼──────┐
│ NOS │
│ Operating │
│ System │
└──────┬──────┘
│
┌──────▼──────┐
│ Hardware │
└─────────────┘
The long-term objective is to allow the programming language, compiler, kernel, memory model, resource-management architecture, and hardware interface to cooperate instead of being designed as isolated layers.
NOL can still exist independently of NOS.
NOL is intended to provide the capabilities required for serious native and systems programming, including work in areas such as:
- integer and numeric computation
- explicit memory access
- arrays and byte-level indexing
- structured control flow
- native functions
- comparison and boolean operations
- bitwise operations
- address and pointer semantics
- explicit data layout
- low-level system interfaces
- direct hardware-oriented programming
- native executable generation
The grammar and syntax are still evolving.
Until the language grammar reaches a stable specification, examples published here should be considered experimental rather than permanent syntax guarantees.
No Hidden Runtime by Default
One of NOL's design goals is to make computational cost visible.
Operations that require resources should ideally expose those requirements rather than silently invoking large runtime subsystems.
The project therefore investigates minimizing or eliminating dependencies on mechanisms such as:
Mandatory GC
General-purpose hidden heap allocation
Large language runtimes
Implicit object metadata
Unnecessary data copying
Unpredictable background runtime work
This does not mean every abstraction is forbidden.
The goal is controlled abstraction: abstractions whose cost can be understood, measured, and lowered efficiently.
Copying data repeatedly between application, runtime, kernel, and device layers can become a significant systems cost.
NOL and NOS are being designed with zero-copy and ownership-transfer techniques in mind.
The long-term architecture explores data paths closer to:
Device / Resource
│
▼
Owned Region
│
▼
Application Processing
│
▼
Ownership Transfer
rather than unnecessary sequences of intermediate copies.
Actual performance characteristics will be published only after reproducible benchmarks are available.
NOL is designed with performance as a primary architectural concern.
However, the project does not treat architectural intent as benchmark evidence.
Claims such as:
"NOL is faster than C"
"NOL beats GCC"
"NOL beats Clang"
require controlled, reproducible benchmarks and equivalent implementations.
The project intends to compare generated native code against established toolchains using measurable criteria such as:
- execution time
- CPU cycles
- instruction count
- executable size
- memory footprint
- allocation behavior
- startup latency
- cache behavior
- system-call overhead
- data-copy overhead
- energy efficiency
Until such measurements are independently reproducible, performance advantages should be considered research objectives rather than established facts.
NOL places unusual emphasis on compiler reproducibility.
A compiler that can compile itself is important.
A compiler that can compile itself repeatedly and converge to an identical result is stronger.
The intended progression is:
Bootstrap
↓
Self Compilation
↓
Stable Self Compilation
↓
Byte-Identical Fixed Point
↓
Reproducible Verification
This is one of the project's principal technical milestones.
NOL investigates whether reducing implicit runtime behavior can also reduce system complexity and attack surface.
Areas of interest include:
- explicit resource ownership
- deterministic memory regions
- architectural isolation
- reduced runtime state
- restricted cross-domain access
- compiler-enforced boundaries
- minimal trusted computing components
- hardware-aware isolation
- capability-oriented resource control
NOL does not claim to make software unhackable.
Security properties require formal analysis, implementation review, fuzzing, adversarial testing, and independent validation.
NOL is also exploring language characteristics that may make program generation and analysis easier for machine intelligence.
Potential areas include:
- reduced syntactic ambiguity
- deterministic semantics
- explicit resource relationships
- compact intermediate representations
- machine-readable program structure
- predictable transformations
- compiler-verifiable generated code
The objective is not to design a language exclusively for AI.
The objective is to investigate a language that can be understandable and efficient for both humans and automated software-generation systems.
The current high-level development order is:
Language Core
↓
Compiler Front End
↓
Native Code Generation
↓
Self Hosting
↓
Compiler Fixed Point
↓
Reproducible Validation
↓
Kernel Bootstrap
↓
NOS System Layers
Compiler correctness comes before operating-system feature expansion.
| Area | Status |
|---|---|
| Language architecture | 🟡 Active development |
| Language specification | 🟡 Active development |
| Lexer / parser | 🟡 Active development |
| Intermediate representation | 🟡 Active development |
| Native code generation | 🟡 Active development |
| x86-64 support | 🟡 Active development |
| ARM64 support | ⚪ Planned |
| Self-hosting | 🟡 In progress |
| Byte-identical fixed point | ⚪ Not yet declared complete |
| Bare-metal bootstrap | ⚪ Planned |
| NOS kernel integration | ⚪ Planned |
| Stable public release | ⚪ Not yet available |
Status indicators are intentionally conservative.
A feature should not be considered complete merely because a prototype exists.
NOL is not currently presented as:
- a finished production language
- a proven replacement for C or C++
- a benchmark champion without published evidence
- an unhackable programming environment
- a completed operating system
- a language with a permanently frozen grammar
- a project that considers prototype success equivalent to production readiness
NOL is a systems-language research and engineering project attempting to test whether a more vertically integrated computing architecture can provide meaningful advantages.
The broader vision is larger than introducing another programming language.
The project aims to investigate a stack in which:
Language
Compiler
Memory Model
ABI
Kernel
Resource Control
Security Model
Hardware Interface
are designed as parts of one coherent architecture.
If successful, NOL should not merely provide a different way to write conventional software.
It should make it possible to explore a different relationship between software and the machine executing it.
- Stabilize the core grammar
- Complete required operators
- Stabilize arrays, strings, indexing, and addressing
- Define function and calling semantics
- Publish the language specification
- Expand compiler regression testing
- Complete the native compilation pipeline
- Stabilize executable generation
- Remove bootstrap dependencies where practical
- Achieve reliable self-compilation
- Establish reproducible Stage 2 / Stage 3 comparison
- Publish compiler verification tools
- Mature x86-64 support
- Develop ARM64 backend support
- Define stable native ABI rules
- Expand executable-format support
- Establish cross-platform compiler validation
- Native kernel bootstrap
- Memory/resource architecture
- Terminal and shell
- Storage
- Networking
- Graphics/compositor
- Device interfaces
- Security/isolation architecture
- Package and build tooling
- Debugging tools
- Language server support
- Documentation
- Standard facilities
- Interoperability layers
- Migration/transpilation tools for existing languages
NOL is an experimental project and contributions are welcome.
Useful contribution areas include:
- compiler engineering
- programming-language design
- parser and lexer development
- native code generation
- x86-64 and ARM64 architecture
- operating-system development
- executable formats
- testing and fuzzing
- benchmarking
- security analysis
- documentation
- formal methods
- performance engineering
Before proposing major architectural changes, please open an issue describing the problem, proposed approach, expected advantages, and possible trade-offs.
Correctness and reproducibility take priority over feature count.
The project follows a simple principle:
Do not call it solved until it is measured, tested, and reproducible.
A prototype is evidence of possibility.
A passing test is evidence for a specific test case.
A reproducible result is evidence.
A verified fixed point is evidence.
NOL development aims to keep those distinctions explicit.
NOL is distributed under the MIT License.
See LICENSE for details.
GitHub: https://github.com/CoCoRiCo/NOL
Native. Deterministic. Explicit. Measurable.
Building upward from the machine instead of downward from the runtime.