"An Idiot admire complexity, a genius admire simplicity" Terry A. Davis
-
"Master All, Ace One" Boykisser
-
-
Overview
-
Sterling is a low-level, strongly typed, systems programming language designed for performance, ABI stability, C interoperability, and full control over memory and hardware. It supports metaprogramming, hot-reloading, inline and raw assembly, and is built for multi-file compilation. It also introduces memory safety primitives and modern low-abstraction control flow enhancements.
-
-
This Document is a work in progress, features are not yet implemented and i use this as a design document to stay true to my vision
-
-
File Extensions (subject to change)
-
-
Source files: .stg
-
Header files: .sth
-
-
-
Function
-
-
-
Qualifiers
-
Every function must declare its linkage explicitly:
-
-
- //globally visible, default linkage
-static //translation unit-local only
-inline //inline-only, no symbol emitted
-asm //raw assembly function, globally visible
-static_asm //raw assembly function, TU-local only
-inline_asm //inline-only asm, no symbol emitted
-async //for fiber (coroutine) ??
-
-
-
Syntax
-
All functions must explicitly declare their return type. The only exception is void, which may be omitted for brevity when no return value is intended.
-
-
-u32 add(u32 a, u32 b) {
- return (a + b);
-}
-
-inline u32 max(u32 a, u32 b) {
- return ((a > b) ? a : b);
-}
-
-exit() {
- // equivalent to void exit()
-}
-
-
-
Assembly
-
Write raw x86_64 assembly using fn_asm or fn_static_asm. Symbol, section, and global declaration are implicit.(placeholder)
-i8, i16, i32, i64 // signed integers
-u8, u16, u32, u64 // unsigned integers
-f32, f64 // 32-bit and 64-bit IEEE floats
-bool // 1-byte boolean, 0 or 1 only//maybe but not a fan of them
-char // 1-byte character (UTF-8)
-
-
-T* // Pointer to type T
-ptr* // Special pointer with implicit coercion allowed
-void* // Opaque pointer with explicit cast required
-
-
-
-typedef struct {
- u32 x = 5;
- u32 y;
-} vec2u;
-
-vec2u a = {}; // x = 5, y = 0
-vec2u b = {0}; // x = 0, y = 0
-vec2u c; // x = 0, y = 0
-
-
-u32 raw_val @raw; // raw_val = ? can be poopoo data
-
-
-
-
-
-
Memory Model
-
-
Manual memory management by default. Variables are zero-initialized unless marked @raw. All layout is predictable and cache-friendly. Custom allocators are encouraged.
-
-
Stack: locals
-
Heap: explicit alloc/free
-
Inline: structs passed by value
-
-
-
-
-
-
-
-
Control Flow
-
-
-
Loop
-
Sterling introduces tagged loops and escape blocks for structured yet flat nested loop
- behavior:
Runtime-initialized aligned linear arrays can be used to simulate array-of-array structures, where all memory layout is controlled explicitly with offsets:
Insertions and deletions move memory explicitly, re-aligning if needed.
-
-
-
-
-
Dynamic Linking
-
-
Sterling does not rely on dynamic linking by default. Static linking is favored for OS and runtime simplicity. Dynamic linking may be optionally implemented via host-defined facilities in the future.
-
-
-
-
-
Metaprogramming
-
-
also i am not thinking of having something as close as what jai have, if you want solid meta programming look out for when jai become open beta
-
-
Metaprogramming
-
Sterling supports compile-time metaprogramming via the meta keyword. Meta constructs are evaluated at compile time and allow structured code generation, reflection, and type introspection.
-
-
Capabilities
-
-
Generate code at compile-time (functions, structs, constants)
-
Inspect type properties: size, alignment, fields
-
Enumerate over struct fields, enum variants, function parameters
-
Branch compile-time logic via meta if, meta match
-
Define metafunctions using meta fn (not emitted at runtime)
-
Support platform/target-specific compilation logic
-
-
-
Restrictions
-
-
Meta code must be side-effect free (pure, deterministic)
-
No runtime reflection or dynamic codegen
-
No access to I/O, filesystem, or arbitrary memory
-
All meta-expansions must type-check
-
Expansion depth and iteration count are bounded
-
-
-
Example
-
-meta print_fields_of(T) {
- for (field : fields(T)) {
- print("Field: ", field.name, " of type ", field.type);
- }
-}
-
-meta if sizeof(T) > 64 {
- fn_inline void fast_copy(T* dst, T* src) { ... }
-}
-
-
-
Compiler Meta API (proposed)
-
-meta_typeof(expr)
-meta_sizeof(T)
-meta_alignof(T)
-meta_fields_of(T)
-meta_fn_params(fn)
-meta_platform() // e.g., "linux", "windows"
-meta_codegen(name, ast_block) // gated for advanced use
-
-
-
-
-
-
-
ABI and Interop
-
-
TODO: Specify ABI model (System V AMD64), calling convention details, struct/pointer representation rules. C interaction, emiting ELF/COFF/Mach-O symbol tables .o
-
-
-
-
-
Threading
-
-
TODO: Describe standard threading model, scheduler integration, context switching, green threads API.
-
-
Fiber (Coroutine)
-
Using user managed stack that is allocated (usefull for userland threading)
-
-
-
Each fiber as:
-
-
Its own manually allocated stack
-
Registers saved/restored on yield and resume
-
Tracked by a runtime scheduler (or user managed)
-
-
fiber_yield() triggers context switch, calling back into a fiber scheduler
-
Can be pooled, migrated between threads, or used for deterministic execution (e.g., game loops, scripting)
-
-
-
Internal Scheduler Model
-
-
A circular queue or priority queue of fiber_ids
-
fiber_yield() pushes current fiber to back of queue
-
fiber_resume() pulls next and switches context
-
-
This allows async, non-blocking logic to be modeled without system threads.
-
-
Safety and ABI Guarantees
-
-
-
define the fiber stack layout, allowing for precise control (great for embedded targets)
-
fiber_spawn can return errors if stack is misaligned or exhausted
-
ABI guarantees for fiber functions: must follow a calling convention you define (e.g., preserved registers)
-
-
Thread
-
-
-
Created via OS APIs (e.g., pthread, CreateThread, or syscall wrappers)
-
Each thread runs independently; shares global heap and data structures
-
You wrap OS threads and assign them entry points via thread_spawn
TODO: Describe native rendering interfaceI have been thinking about supporting amd gpu acceleration with very few set of actual call, very fewer than opengl or other, but i will focus only on one hardware at first
All drivers run as fully unprivileged user processes
-
No driver registration or kernel mediation required
-
Drivers communicate with hardware via explicit kernel-exposed capability channels
-
No dynamic linking or privileged probing allowed
-
Users can run or replace any driver without OS permission
-
-
-
Graphics System
-
-
No GPU support, no shaders
-
Software renderer processes draw via shared memory
-
DE composites framebuffers deterministically
-
-
-
Programming Language Requirements
-
-
Manual memory management
-
Low-level data layout control
-
Inline assembly support
-
Pattern matching and compile-time macros
-
No runtime, no global init, no dynamic linking
-
-
-
Execution Model
-
-
Programs are spawned with exact buffer and token permissions
-
No shared global state
-
All IO is mediated via explicit capability-based services
-
Everything is inspectable and reproducible
-
-
-
Sandboxing Model
-
All processes are isolated via strict memory boundaries and capability-scoped access. No process can access global state, shared memory, or system calls without explicit capability grants.
-
-
Memory Layout
-
- +-----------------------+
- | Code (RX) |
- +-----------------------+
- | Data (RW) |
- +-----------------------+
- | Shared Buffers (RWX?) | ← only if explicitly mapped by kernel
- +-----------------------+
- | Stack (RW) |
- +-----------------------+
-
-
-
Process Launch
-
-
Preallocated memory map (no heap growth)
-
Passed a syscall pointer table, token list, and init buffer
-
Cannot request global system resources directly
-
-
-
Capability Enforcement
-
All access is mediated via capability tokens, handed off securely:
Token scope, rights, and duration enforced by kernel
-
No access without explicit grant
-
All capability use is auditable and revocable
-
-
-
Filesystem Abstraction
-
-
No global file system
-
Programs receive only memory buffers with scoped access
-
Read/write must go through kernel-mapped tokens
-
-
-
Driver Isolation
-
-
Drivers are userland processes only
-
No direct port I/O or DMA access
-
Hardware is accessed via kernel-exposed capability channels
-
-
-
IPC
-
-
All inter-process communication is routed via the kernel
-
Uses named ports and token-authenticated message queues
-
No shared memory by default
-
-
-
Future Additions
-
-
Deterministic scheduler
-
Audit trail of all token activity
-
Formal capability typing system
-
-
-
-
Philosophy
-
This OS is not a POSIX clone. It is a deterministic, capability-secure, user-controlled computing environment built to reject legacy complexity and embrace verifiable simplicity.
All drivers run as fully unprivileged user processes
+
No driver registration or kernel mediation required
+
Drivers communicate with hardware via explicit kernel-exposed capability channels
+
No dynamic linking or privileged probing allowed
+
Users can run or replace any driver without OS permission
+
-
-
-
Login
-
-
-
-
+
Graphics System
+
+
No GPU support, no shaders
+
Software renderer processes draw via shared memory
+
DE composites framebuffers deterministically
+
+
+
Programming Language Requirements
+
+
Manual memory management
+
Low-level data layout control
+
Inline assembly support
+
Pattern matching and compile-time macros
+
No runtime, no global init, no dynamic linking
+
+
+
Execution Model
+
+
Programs are spawned with exact buffer and token permissions
+
No shared global state
+
All IO is mediated via explicit capability-based services
+
Everything is inspectable and reproducible
+
+
+
Sandboxing Model
+
All processes are isolated via strict memory boundaries and capability-scoped access. No process can access global state, shared memory, or system calls without explicit capability grants.
+
+
Memory Layout
+
+ +-----------------------+
+ | Code (RX) |
+ +-----------------------+
+ | Data (RW) |
+ +-----------------------+
+ | Shared Buffers (RWX?) | ← only if explicitly mapped by kernel
+ +-----------------------+
+ | Stack (RW) |
+ +-----------------------+
+
+
+
Process Launch
+
+
Preallocated memory map (no heap growth)
+
Passed a syscall pointer table, token list, and init buffer
+
Cannot request global system resources directly
+
+
+
Capability Enforcement
+
All access is mediated via capability tokens, handed off securely:
Token scope, rights, and duration enforced by kernel
+
No access without explicit grant
+
All capability use is auditable and revocable
+
+
+
Filesystem Abstraction
+
+
No global file system
+
Programs receive only memory buffers with scoped access
+
Read/write must go through kernel-mapped tokens
+
+
+
Driver Isolation
+
+
Drivers are userland processes only
+
No direct port I/O or DMA access
+
Hardware is accessed via kernel-exposed capability channels
+
+
+
IPC
+
+
All inter-process communication is routed via the kernel
+
Uses named ports and token-authenticated message queues
+
No shared memory by default
+
+
+
Future Additions
+
+
Deterministic scheduler
+
Audit trail of all token activity
+
Formal capability typing system
+
+
+
Philosophy
+
Not a POSIX clone. It is a deterministic, capability-secure, user-controlled computing environment built to reject legacy complexity and embrace verifiable simplicity.