Church Machine

λ Church Machine

Ti60 F225
LED0
Boot
LED1
Run
LED2
Fault
LED3
Done
← DWRITE CR3[0]
CR0-CR15 -- 128-bit Context Registers (4 x 32-bit words)
CR Detail
DR0-DR15 -- 32-bit Values (DR0 = zero)
Gate Log — mLoad / mSave from last Step
Machine Architecture
Editor
0
1
2
3
4
5
pre-boot 0b000000
Ready. Write Church assembly and click Assemble.
Namespace Table -- Golden Token Entries
Memory — Word-Addressed Dump
Abstraction Catalog -- 9 Layers, 46 Abstractions
Select an abstraction
Click any abstraction on the left to see its methods, permissions, and how it fits into the CR6/CR14 canonical form.
LUMP Repository
Select a lump
Click any lump on the left to see its methods, pet names, MTBF, deployment info, and capabilities.
Execution Trace 0 rows
# PC Op Cond Dst Src Description DR0DR1DR2DR3 DR4DR5DR6DR7 DR8DR9DR10DR11 DR12DR13DR14DR15 NZCV STO
⬡ Hardware Build Generate synthesisable RTL for your target FPGA

In 1843, Ada Lovelace wrote the first computer program — Note G, an algorithm for computing Bernoulli numbers. It was not just code. It was the first first-class program: it passed functions as arguments to other functions, not just values.

This is the vital distinction. Basic machine code (Turing) moves numbers between registers — ADD R0, R1, R2 adds two values, nothing more. CLOOMC is different. In CLOOMC, a variable can hold a function, pass it to another function, and return a function as a result. let double = \x -> x * 2 creates a function. let apply = \f x -> f(x) passes that function as an argument. Ada did this in 1843 — Alonzo Church formalised it in 1936 as the lambda calculus.

Type let x = 2 + 3 and you are writing what Ada wrote. To see her original algorithm as Church Machine code, click Create and select the Bernoulli example.

λ>
History
Abstractions & Methods
Concepts
Select a concept or instruction
Click any item on the left to see details.
The Church Machine
Figures
Select a document or figure
Click any document on the left to view it, or click a figure to see the diagram.
♻ Garbage Collection
PP250 four-phase deterministic GC — click once per phase to step through
—
NS entries
—
Freed slots
—
Freed words
—
Live entries
1
Mark Set G=garbage on every valid NS entry — pessimistic assumption
2
Scan Walk all CR roots + call stack; mark reachable entries live
3
Sweep Find entries still flagged garbage; build reclamation list
4
Clear Zero NS entries + object words; bump version; flip GC polarity
Open Source Community
CLOOMC is free, open source, and community-driven. Law 6: Open Source.
Loading repositories...
Recent Activity
Loading commits...
Contributors
Loading contributors...
Quick Links
↑
Push to GitHub
Export the current simulator source to the connected repository. Every file is updated in a single commit.
↓
Browse Library
Fetch shared abstractions from the Mum Tunnel Library. Search by language or author, then install into your namespace.
↑
Publish Abstraction
Share your compiled abstraction with the community. It will appear in the Mum Tunnel Library for others to import.
Get Started — Have fun, don't worry, your mistakes will all be found and fixed. Above all, believe in a safe digital future we can all enjoy, built by the people, for the people.
FPGA Devices
Registered boards and bridge connections
No devices registered. Connect a board via the local bridge to see it here.

Site Map

All 53 HTML pages in the Church Machine project.

Simulators
Home — Landing Page CTMM Simulator — Church-Turing Meta-Machine Church Machine IDE — This page
Documents & Patents
The Six Laws of CLOOMC — Foundational security principles CTMM Patent Portfolio — Patent application index CTMM Unified Patent Submission — Full patent document Church Machine — Business Plan — Full business plan document Church Machine — Investor Deck — 15-slide presentation
Technical Figures (45)
Figure A1: Abstract GT Address Space Figure 21: Ada Lovelace Programming Model — Bernoulli Sum-of-Squares Figure 10: Atomic Abstraction Architecture — 7 Zeroes Figure 3: B-bit Capability Propagation Control Figure 11: Boot Sequence State Machine — 5-Phase Hardware Initialization Figure 16: Church Numeral Method Dispatch Figure 8: Pure Church Processor Block Diagram Figure 26: Compiler-Security Separation Figure 10: Conventional vs CTMM Architecture — Attack Surface Elimination Figure 17: DATA Objects — Church/Turing Bridge Figure 9: Three Dispatch Styles — Same CALL, Three Resolutions Figure 1: Dual-Gate Trusted Security Base Architecture Figure 15: Five-Phase Boot Sequence Figure 2: GT Format and Type Field Figure 14: Hello Mum — Encrypted Capability Tunnel Figure A2: Home Base Tunnel Figure 20: HP-35 and SlideRule Opcode Distribution Figure 6: Lambda Calculus to CTMM Hardware Mapping Figure 7: LAMBDA Clamp — Macro-Like Code Reuse Figure 1: LAMBDA CR6 Idempotent Self-Invocation Flow Figure 3: LAMBDA Machine-Status Fast Path Figure 5: Non-Nestable LAMBDA with CALL-Mediated Nesting Figure 4: LAMBDA vs. CALL Execution Paths Figure A4: Local Peripheral Autonomy Figure 5: Machine-Status Fast Path Figure 13: Mint Abstraction Nesting & Domain Purity Figure 12: mLoad Validation Pipeline — Five Sequential Checks Figure A3: MTBF Qualification Tiers Figure 24: Multi-Language Compilation to Universal Target Namespace Architecture Figure 13: Network Transparency via F-bit and Tunnel Keys Figure 3: Why No Counter — Software Drives, Hardware Follows ChurchNSGate — Unified NS Integrity Architecture Figure 7: PP250 Deterministic Garbage Collection Figure 11: Safe Turing Abstractions Figure 28: Scale-Free Security Model Figure 25: Single-Lump CALL Split Figure 4: Self-Describing Stack Frames Figure 6: Self-Describing Stack Frames Figure 14: Three Dispatch Styles Figure 2: Three Loop Styles — LAMBDA CR6 Dominates Figure 8: Encrypted Capability Tunnel Between Meta Machines Figure 12: Unified Address Space Figure 27: Upload-Driven Lifecycle Figure 9: Vulnerability Elimination by Construction