xHunOS Kernel Architecture & Metaphysical Computation
Abstract
“This paper presents the formal design and mathematical foundations of xHunOS, an air-gapped operating system executing entirely in Machine-Mode on a custom-designed 64-bit RISC-V (RV64) CPU at 300 MHz. By utilizing direct physical addressing (satp=Bare) and eliminating multi-ring privilege transitions, memory virtualization, and GPU driver stacks, xHunOS achieves ~100× reduction in CPU execution cycles, 50mW active power consumption, and 100µW deep standby via hardware WFI power-gating.”
1. Custom 64-Bit RISC-V Silicon & Direct Physical Addressing (satp=Bare)
Mainstream general-purpose processors and operating systems burn enormous amounts of energy on memory virtualization: 4-level page table walks (MMU), TLB miss penalties, page faults, and Ring 3 to Ring 0 context-switching overhead consume tens of thousands of cycles per user interaction.
xHunOS avoids this by running directly on our custom 64-bit RISC-V processor in Machine-Mode (M-Mode). The supervisor address translation register is permanently set to Bare mode (`satp = 0`). Physical addresses are identical to virtual addresses across all 64 bits with zero address translation latency and zero TLB misses. The entire on-chip SRAM and physical flash reside in one flat, deterministic memory space.
; Custom 64-bit RISC-V Machine-Mode Physical Entry
; satp = 0 disables virtual memory translation entirely.
; All memory operations are physical 1:1 with zero MMU latency.
csrw satp, zero ; satp = 0 (Bare mode: Physical Addressing)
; Set up Machine Status Register (MSTATUS)
li t0, (1 << 3) ; MIE = 1 (Machine Interrupt Enable)
csrs mstatus, t0
; Assign Heavenly Stems register base
la sp, _stack_top ; 辛 (sp): Physical stack top
la gp, _global_sym ; 全局符号表基址
; Jump directly into TaiChu Root Task in M-Mode
jal taichu_entry2. DaoFS: Continuous Sector Geometry & Zero-Seek Flash I/O
Traditional filesystems (Ext4, Btrfs, NTFS) rely on B-trees, indirect pointers and journaling, all of which add write amplification and variable-latency metadata paths. A single small file update on Ext4 can produce four or more independent writes. That variability is tolerable on a general-purpose machine, but it is a poor fit for any workload that wants a stable timing envelope.
DaoFS is the direct evolution of TempleOS's RedSeaFS. Inode trees and indirect pointers are eliminated: every file occupies one unbroken run of 2048-byte sectors, matching raw SPI flash geometry. Address translation is a single extent lookup rather than a tree walk — O(1) from file handle to physical sector. Contiguity is maintained by construction and paid for on free: releasing a file compacts the extents above it. DaoFS therefore trades allocation cost for read locality, the opposite of a copy-on-write B-tree.
DaoFS as specified here is not crash-consistent. Compaction rewrites live extents, so a power loss in the middle of a compaction can leave the volume in a state no reader can interpret. This is a stated requirement for v0.2, not a property the current draft has. Meeting it means choosing one of two designs: write the new extent before retiring the old one and commit the switch in a single checksummed superblock sector, or keep an append-only allocation log that a repair tool can replay. Whichever is chosen must survive injected power loss at every write boundary; until it does, the system must not be described as crash-safe.
Physical Sector Base Size (Direct Flash)
One unbroken sector run per file; compaction on free, never scatter
File handle to physical sector in one extent lookup
3. The 49-Stalk Yarrow Ritual: Combinatorial Fairness and Physical Entropy
Commercial divination software draws from a pseudorandom generator — Mersenne Twister, PCG, or /dev/urandom — and maps its output onto the hexagram space. The result is a flat distribution that erases the ritual's defining asymmetry: in the classical 揲蓍法 procedure the four Yao archetypes are not equiprobable. Reproducing the ritual therefore requires two separate things: the correct distribution, and an unpredictable draw.
The distribution is a combinatorial fact, not a physical one. Splitting 49 stalks into two heaps, reserving one (挂一), and reducing modulo four at each of three stages leaves 24, 28, 32 or 36 stalks. Enumerating the four possible splits per stage yields the classical probabilities below. This is an identity of the procedure: it depends only on the number 49, the reserve-one rule and the three-stage structure. It can be proven on paper, and it holds for a perfectly random split.
The table above is a statement about the procedure, not about the physics. Two hands splitting a bundle can be biased: a practised operator, a worn bundle, or a table with a groove all shift the split distribution. Claiming that the ritual is a hardware entropy source therefore requires measurement rather than assertion. Collect a large recorded sample, estimate min-entropy per draw instead of Shannon entropy, and test the empirical Yao distribution against the combinatorial expectation with a goodness-of-fit statistic. v0.2 publishes that estimate with a confidence interval. If per-draw min-entropy falls below the threshold the application needs, the ritual output is mixed with a dedicated hardware source rather than used raw.
| Yao Archetype (四象) | Stalk Remainder (策数) | Theoretical Probability | Philosophical Meaning & Mutation |
|---|---|---|---|
| Old Yang (老阳, 9) | 36 stalks remaining | 3 / 16 (18.75%) | Extreme Yang · Mutational Moving Line |
| Young Yin (少阴, 8) | 32 stalks remaining | 7 / 16 (43.75%) | Growing Yin · Static Quiescent Line |
| Young Yang (少阳, 7) | 28 stalks remaining | 5 / 16 (31.25%) | Nascent Yang · Static Creative Line |
| Old Yin (老阴, 6) | 24 stalks remaining | 1 / 16 (6.25%) | Extreme Yin · Mutational Moving Line |
4. Fixed-Width 16-Bit Lexer & ZAsm Sovereign Registers
Mainstream compilers treat CJK text as variable-length UTF-8, so indexing character n requires scanning from the start of the string and every slice must be boundary-checked. xHunOS stores source text as fixed 16-bit code units — the Basic Multilingual Plane — one unit per array slot. In the xLang lexer a Chinese ideograph is a single 2-byte word, so character n sits at offset 2n and tokenisation needs no slice arithmetic. The trade is explicit: the BMP covers 65,536 code points, enough for everyday Hanzi, kana and hangul, but not for emoji, rare personal-name characters or CJK Extension B and beyond. xHunOS does not pretend otherwise; supplementary characters are out of scope for the source encoding.
ZAsm (Zen Assembly) maps the 64-bit general-purpose registers to the Ten Heavenly Stems (RAX → 甲, RBX → 乙, RCX → 丙, RDX → 丁) and the condition flags to the Eight Trigrams (乾/坤/震/坎). This is a notation, not a security control: it makes hand-written low-level code easier to read and harder to confuse with C, and it is deliberately not claimed to resist decompilation. Tooling reads symbols, and the symbols are published.
5. Comparative Systems Architectural Benchmark
| Architectural Metric | Mainstream Linux (6.x Kernel) | TempleOS (Legacy Precursor) | xHunOS (玄魂OS) |
|---|---|---|---|
| Complete OS Image Footprint | Several Gigabytes to Tens of GB | 16.8 MB | 25.1 MB target (with Ephemeris & Fonts) |
| Cold-Boot Target (Interactive Shell) | 15 to 45 seconds | 0.2 seconds | 0.1 s target (Direct SPI Flash) |
| Memory & Privilege Model | Dual Ring 3/0 Paging Isolation | Ring 0 Single Address Space (Identity-Mapped) | Ring 0, Identity-Mapped 1:1, 1 GiB Huge Pages |
| Character Subsystem Standard | UTF-8 Multi-byte Variable Encoding | 8-Bit Extended ASCII | Fixed-Width 16-Bit (BMP) Ideographs |
| Network & Isolation | Active TCP/IP & Continuous Telemetry | Air-Gapped (No Network Stack) | Absolute Air-Gap: No Network Stack, No Radio Driver in Kernel |
6. Offline Threat Model and v0.2 Release Requirements
xHunOS is described as air-gapped, and that description is accurate in a narrow sense: the kernel contains no network stack and no radio driver, so there is no remote surface to attack. It is not a security guarantee. This section states plainly what the air gap does and does not cover, and lists the gates a build must pass before it is offered publicly. None of the requirements below is implemented today; they are acceptance criteria for v0.2, and this page describes them as such.
6.1 What the air gap covers, and what it does not
- Covered: remote intrusion
There is no socket, no Wi-Fi manager and no update channel, so an attacker cannot reach the machine over a network. This removes an entire class of compromise rather than mitigating it.
- Not covered: physical access
Everything runs in Ring 0, and there is no login boundary between the operator and the kernel. Anyone who can touch the machine or its storage is root. Without encryption at rest, removing the flash chip is enough to read every file.
- Not covered: hostile media
The kernel parses images, filesystems and DolDoc files from removable media at the highest privilege level. A parsing bug is a total compromise, because there is no lower ring to fall back to.
- Not covered: the boot path
An unsigned image and a tampered image are indistinguishable to the firmware. Trust in a build has to come from a signature that can be verified offline, not from the distributor's assurance.
6.2 Release gates for v0.2
Each item below is a requirement that must be implemented and tested before a public image ships. The list is deliberately short and every gate is falsifiable; a gate that cannot be demonstrated is treated as unmet. The status of each is tracked on the download page.
- R1Encryption at rest
DaoFS volumes are encrypted with an authenticated cipher (XChaCha20-Poly1305 or AES-256-XTS), with the key derived from a passphrase through Argon2id. Key material never reaches the framebuffer, DolDoc output or a crash dump. Gate: a removed flash chip yields no plaintext.
- R2Crash consistency
DaoFS compaction commits atomically, and a repair tool can rebuild or roll back an interrupted commit. Gate: fault injection at every write boundary leaves a mountable volume.
- R3Signed images
Every released image carries an Ed25519 signature over the full payload, and the published fingerprint is verifiable offline from a second machine. Gate: a single flipped byte is rejected before the kernel starts.
- R4Data export
A complete export path writes every user file to removable media in a documented, plain format. Gate: a user can leave the system without a second xHunOS machine.
- R5Recovery mode
A read-only boot path can mount a damaged DaoFS volume and copy data out. Gate: files are recovered from a deliberately corrupted volume.
- R6Crypto-erase and rekey
Wiping a volume destroys the key rather than overwriting sectors, because flash wear levelling and bad-block remapping make overwrite unreliable. Gate: a wiped device exposes no recoverable data at the chip level.
- R7Memory hygiene
Key material and plaintext buffers are zeroised on release, and task exit scrubs its stack. Gate: a memory dump taken after a session contains no key bytes.
- R8Entropy measurement
The per-draw min-entropy study described in section 3 is published with its confidence interval. Gate: the measured value meets the threshold for the stated divination use, or the ritual output is mixed.
- R9Reproducible builds
The toolchain is pinned and the image is bit-for-bit reproducible, with published hashes. Gate: an independent party rebuilds the image and obtains an identical digest.
7. Architectural Efficiency & Power: Cycle-Level Proof
Rather than benchmarking synthetic loads, xHunOS hardware efficiency is measured at the fundamental instruction and power dissipation boundaries. By eliminating runtime abstraction layers, memory paging walks, and continuous background daemons, the operating system achieves radical reductions in execution cycles and power consumption.
7.1 Architectural Execution & Power Matrix
| Metric / Dimension | xHunOS (Ring 0) | Modern OS (Android / Linux / Win) | Efficiency Gain | Architectural Mechanism |
|---|---|---|---|---|
| Installed OS image | 25.1 MB (design target) | 4–20 GB Linux / Android | ≈160–820× smaller | Elimination of bloated frameworks & runtimes |
| Cold boot to interactive shell | 0.1 s (design target) | 15–45 s | ≈150–450× faster | SPI Flash direct execution, no daemon initialization |
| CPU execution work (UI / 3D Render) | ~1,000 cycles | ~100,000 cycles | ≈100× less CPU work | Direct interrupt to framebuffer vs VM + Ring 3/0 switches |
| Active power consumption | 0.05 W (50 mW) | 3.0 – 5.0 W | ≈60–100× lower drain | 300 MHz clock sufficient, on-chip SRAM, zero bus power |
| Deep standby power (Lid closed) | 0.0001 W (100 µW) | 0.1 – 0.2 W (100–200 mW) | ≈1,000–2,000× lower drain | Hardware HLT physical deep sleep, zero background daemons |
7.2 Detailed Analysis of Power & Instruction Efficiency
CPU Usage Savings: 10× to 100× Less Work
For every 100 instructions Android executes to complete a task, xHunOS only executes ~1. When rendering a 3D character or responding to user input, modern systems pass input through the kernel, wake up the JVM runtime, translate UTF-8 text (30 cycles/char), cross Ring 3 to Ring 0 (1,500 cycles), traverse virtual memory page tables (100 cycles), and query the GPU driver stack (~100,000 cycles total). In xHunOS, the hardware interrupt directly fires a Ring 0 function, reads 16-bit Hanzi text (1 cycle), computes the transformation, and writes directly into the physical framebuffer (1 cycle) in ~1,000 cycles.
Active Power Savings: 50× to 100× Less Battery Drain
Because xHunOS requires 100× less CPU work, processors do not need to run at 3.0 GHz. A RISC-V or x86 core running at 300 MHz feels equally fast and responsive. Running 3D calculations on a smartphone forces CPU/GPU clocks high and constantly fetches data across external RAM buses (drawing 3W to 5W). xHunOS runs at low clock frequencies with zero background tasks and on-chip SRAM locality, consuming only 0.05W (50mW).
Standby Power Savings: 1,000× to 2,000× Less Battery Drain
Modern operating systems wake the processor hundreds of times per minute even while the screen is off to service Wi-Fi, background telemetry, garbage collection, and paging (drawing 100mW to 200mW and losing ~10% battery overnight). When the lid is closed, xHunOS executes the hardware HLT (Halt) instruction. With zero background processes, the CPU enters physical deep sleep, leaving only a micro-capacitor maintaining the real-time clock and consuming ~100 µW (0.0001W).