HolyC Programming

1. Introduction & Historical Context

HolyC is a low-level, high-performance C-dialect created by the late Terry A. Davis (1969–2018). It serves as both the application language and core kernel programming environment for TempleOS—an independent, 64-bit multi-tasking operating system developed entirely from scratch over a decade[cite: 1].

"HolyC is C with extra features, simplified syntax, and total raw access to the machine. There are no permissions, no barriers, and no virtual memory abstractions."

Unlike conventional general-purpose programming languages designed to scale across thousands of libraries and distinct user permissions, HolyC was built to adhere to a singular, non-traditional philosophy: the entire system should fit within a single developer's head.

2. System Architecture & Kernel Integration

Standard high-level languages rely on complex execution stacks: user spaces, runtime libraries (`libc`), standard input/output abstractions, dynamic linkers (`ld.so`), and system call kernel boundaries[cite: 1].

HolyC bypasses this entire paradigm. Every line of code runs inside Ring 0 (kernel space)[cite: 1].

Key Architectural Properties:

Single Privilege Level: No separation between user space programs and driver/kernel code[cite: 1]. Any function can issue raw hardware I/O instructions.
JIT Assembly Compilation: HolyC source code is compiled directly to x86_64 machine code JIT at execution time via the interactive system shell[cite: 1].
Global Hash Table Symbol Resolution: Instead of linking static `.so` or `.dll` binaries, all functions, constants, and global variables live in a unified system symbol hash table accessible instantly across all running tasks.
Identity-Mapped Memory: Virtual memory address mapping directly matches physical memory address space (no standard page protection or memory segmentation).

3. Key Syntax Extensions & Deviations from C

HolyC keeps standard C constructs like `if`, `while`, `for`, and `switch`, but adds significant syntax enhancements[cite: 1]:

Implicit Print Statements

In HolyC, string literals standing alone on a statement line automatically print to the current task's standard text output buffer without invoking `printf()`[cite: 1]:

// In Standard C: printf("Hello World\n");
"Hello World\n"; 
    

Default Function Parameters

Functions support optional default values directly in their parameters, eliminating function overloading or wrapper boilerplate[cite: 1]:

U0 PrintMessage(U8 *msg, I64 count = 1) 
{
    I64 i;
    for (i = 0; i < count; i++) {
        Print("%s\n", msg);
    }
}

PrintMessage("Testing");    // Prints "Testing" 1 time
PrintMessage("Testing", 3); // Prints "Testing" 3 times
    

Auto-Printing Shell Expressions

Expressions evaluated at the command prompt that do not end in semicolons automatically display their calculated numerical values to the shell console:

// Typing this directly into the shell prompt:
(10 * 5) + 25; // Output: 0x0000004B = 75
    

Variable-Length Argument Arrays (`...`)

HolyC handles variadic function calls using a built-in `argc` and `argv` mechanism automatically generated by the compiler behind the scenes.

4. Data Type System

HolyC replaces standard C variable size specifiers (`short`, `int`, `long`) with explicit bit-length definitions[cite: 1]:

HolyC Type	Bit Width	Byte Size	Type Equivalent
U0	0	0	Void / Return-less Type[cite: 1]
I8 / U8	8	1	Signed / Unsigned 8-bit Integer (Char)[cite: 1]
I16 / U16	16	2	Signed / Unsigned 16-bit Integer[cite: 1]
I32 / U32	32	4	Signed / Unsigned 32-bit Integer[cite: 1]
I64 / U64	64	8	Signed / Unsigned 64-bit Integer[cite: 1]
F64	64	8	Double Precision IEEE Floating-Point[cite: 1]
Bool	8	1	Boolean (`TRUE` = 1, `FALSE` = 0)[cite: 1]

5. Dynamic Compilation & Metaprogramming

Because the HolyC compiler is integrated directly into the kernel memory space, code can dynamically generate, compile, and execute string expressions during runtime seamlessly[cite: 1].

Dynamic Code Execution (`ExeString`)

U0 ExecuteDynamicCode()
{
    // Compiles and executes HolyC source strings at runtime
    ExeString("Print(\"Executed from runtime string!\\n\");");
}

ExecuteDynamicCode();
    

Class Inheritances & Member Offsets

HolyC classes can extend other structures directly without traditional Object-Oriented runtime dispatch overhead[cite: 1]:

class Vector2D {
    F64 x, y;
};

class Vector3D : Vector2D { // Inherits x and y directly
    F64 z;
};

Vector3D v;
v.x = 1.0;
v.y = 2.0;
v.z = 3.0;
    

6. Direct Hardware Access & Built-in Graphics

TempleOS relies on a fixed VGA resolution mode (640x480, 16-color palette)[cite: 1]. HolyC provides immediate access to the global graphics display buffer (`gr.dc`) without calling external windowing system drivers[cite: 1].

Direct Screen Drawing Example

U0 DrawGraphicsDemo()
{
    I64 i;
    
    // Clear screen canvas
    DocClear;
    
    for (i = 0; i < 200; i += 5) {
        // Draws lines directly onto frame context
        GrLine(gr.dc, 100 + i, 100, 300, 100 + i, GREEN);
    }
}

DrawGraphicsDemo();
    

Inline Assembly Integration (`asm`)

Any function can drop straight down into raw x86_64 assembly code without needing specialized compiler intrinsics[cite: 1]:

I64 ReadCPUFlags()
{
    I64 flags;
    asm {
        PUSHFQ
        POP     RAX
        MOV     flags, RAX
    }
    return flags;
}
    

7. Technical Comparison Matrix

Category	Standard C (C11/C17)	HolyC (TempleOS)
Execution Level	User Mode (Ring 3)[cite: 1]	Kernel Mode (Ring 0)[cite: 1]
Compilation Paradigm	Static Ahead-of-Time (AOT)[cite: 1]	Dynamic Just-In-Time (JIT) + AOT[cite: 1]
Memory Protection	Virtual address memory space	Identity-mapped (Unprotected)
Function Default Parameters	No[cite: 1]	Yes[cite: 1]
Assembly Syntax	GNU Inline / Vendor extensions	Built-in `asm {}` blocks[cite: 1]
GUI / Rendering Engine	External Libraries (X11, Wayland, Win32)	Built-in Kernel Framebuffer API[cite: 1]

8. Legacy and Industry Takeaways

HolyC remains a fascinating case study in operating system design, compiler engineering, and software minimalism. It serves as proof that a single engineer could construct an entire computing stack—from kernel to language compiler to graphics subsystem—without reliance on modern enterprise toolchains.

The HolyC Language