Depending on his interpretation of the rules about trapped instructions, one could just build a loop in the x86 page tables. Those are usually a tree linked by pointers, and any page table lookup can create another page fault that creates another lookup that...
Leads to x86 page table MMU magic being turing complete: https://github.com/jbangert/trapcc
And the simplest thing you can do on such a system is just to loop indefinitely, thus creating a simple instruction with a memory access (mov or anything, doesn't really matter, even the instruction fetch for a nop would work) to take infinite time.
In Assembly Hall of Shamejbangert
trapcc
C2013–2026
jbangert / trapcc
trapcc
Computing with traps
27Distinct people
30Mentions
0Explicit recommenders
1.3KGitHub stars
What to know before exploring
What it is
Computing with traps
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year30 dated mentions
Observed mentions: 2013-02-22 00:09:51 UTC to 2026-08-08 09:35:26 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 6 | 2 | 4 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 6 | 2 | 4 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 0 | 2 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
trapcc
Compute with 0 instructions on Intel! Discover the awesomeness of the Intel MMU!
Follow @julianbangert and @sergeybratus for updates. See a demo here:
http://www.youtube.com/watch?v=eSRcvrVs5ug
What is this?
This is a proof by construction that the Intel MMU's fault handling mechanism is Turing complete.
We have constructed an assembler that translates 'Move, Branch if Zero, Decrement' instructions to C source that sets up various processor control tables.
After this code has executed, the CPU computes by attempting to fault without ever executing a single instruction.
Optionally, the assembler can also generate X86 instructions that will display variables in the VGA frame buffer and will cause control to be transferred between the native (display) instructions and 'weird machine' trap instructions.
Why on earth?
To read up on the awesome idea of weird machines and their uses, see @sergeybratus's and @halvarflake's work. In short, we are trying to find hidden state and derive computation of it in unexpected places.
One practical use of this technique is for code obfuscation - many (kernel) debuggers will break due to the frequent context switches (esp. cooperative debuggers like KGDB) and analyzing the binary is going to be extraordinaly confusing, especially if normal X86 instructions and trap instructions are interleaved to do weird control transfer.
Furthermore, out of the many virtual machines only Bochs runs such trap based programs correctly (and there are other tricks to distinguish bochs from a real box).
Getting Started
Go to trapcc/samples_glider
make
Run in bochs (with the included .bochsrc) or on bare metal ( go to grub2, "multiboot (hd0,msdos1)/path/to/samples_glider/kernel.bin , grub 1 uses the kernel command instead)
Go forth and hack
TBD
As always, one of these days we will publish a detailed paper. Until then, please hack around with the code. Share any cool creations and ask any questions on twitter!
Read the full README on GitHubWhat Hacker News says
30 sourcesFrom a computer science POV, it's spooky how Turing-completeness arises spontaneously out of the most mundane data-processing machines. You look at UTS#35, see "Transforms provide a set of rules for transforming text via a specialized set of context-sensitive matching rules." and think, "Ah! Rewrite rules! Those are often Turing-complete! Maybe this one is too!".
And so it is (https://en.wikipedia.org/wiki/Semi-Thue_system#Undecidabilit...).
It's a scary and wonderful part of our world that you can bootstrap so much complexity out of a little iterated self-reference.
My only quibble with the article is in this line...
> The surprise is that it lives in a data format for locale files, shipped in every OS, whose specification doesn't mention the possibility.
... I'm not surprised. After all, the processor that interprets the data format is
Read the rest
Turing-complete not only in its instructions, but in the page table! See https://github.com/jbangert/trapcc
If anything, when you build a system and it starts to get complex, you have to go out of your way to ensure it's decidable and can't accidentally bootstrap the universe.
A variation of this has been done using Intel MMU fault handling. Behold: https://github.com/jbangert/trapcc
This is a proof by construction that the Intel MMU's fault handling mechanism is Turing complete. We have constructed an assembler that translates 'Move, Branch if Zero, Decrement' instructions to C source that sets up various processor control tables. After this code has executed, the CPU computes by attempting to fault without ever executing a single instruction. Optionally, the assembler can also generate X86 instructions that will display variables in the VGA frame buffer and will cause control to be transferred between the native (display) instructions and 'weird machine' trap instructions.
In Subtraction is functionally completeI think that's unnecessary rude.
This thread is about hacking something up and not building a product.
For example imagine somebody shares the "one instruction set computer" (https://en.wikipedia.org/wiki/One-instruction_set_computer) project or x86 MMU being turing complete (https://github.com/jbangert/trapcc). Both are clearly just interesting hacks (which may have some interesting implications about security and what does it mean to be "code" etc) and certainly are not intended to be practical products
In Building Processors from the Ground Upfwiw, linked to from the article:
> As others have shown, we can compute using alphanumeric machine code[1] or English sentences[2], using only the mov instruction[3], or using the MMU[4] as it handles a never-ending double-fault. Here is my contribution to this genre of Turing tarpit: x86 is Turing-complete with no registers.
[1] http://www.phrack.org/issues.html?issue=57&id=15#article
[2] http://www.cs.jhu.edu/~sam/ccs243-mason.pdf
[3] http://www.cl.cam.ac.uk/~sd601/papers/mov.pdf
[4] https://github.com/jbangert/trapcc
In x86 is Turing-complete with no registers (2014)x86 is Turing-complete with no instructions, too: https://github.com/jbangert/trapcc
In x86 is Turing-complete with no registers (2014)Someone made a NISC compiler: https://github.com/jbangert/trapcc
In Movfuscator – Single instruction C compilerin a similar vein, here is an exmple program that runs using only x86 CPU faults.
https://github.com/jbangert/trapcc
In Movfuscator – Single instruction C compilerThey got Turing completeness in just the MMU. This was surely unintended, just like Turing completeness in C++ template expansion and Turing completeness in sendmail configuration files.
Here you go, computation via continuous MMU faults without actually completing any instructions:
https://github.com/jbangert/trapcc
https://www.youtube.com/watch?v=eSRcvrVs5ug
In Intel 80386, part 1: IntroductionThe page table walking hardware on x86 is pretty distinct from the main core, and is Turing complete.
https://github.com/jbangert/trapcc
In How Many Computers Are in Your Computer?You don't even need mov. X86 MMU fault handling mechanism is Turing complete. https://github.com/jbangert/trapcc
In X86 Assembly GuideAnd for the minimalist, the zero-instruction C compiler
https://github.com/jbangert/trapcc
In Movfuscator – A single-instruction C compilerShowing the 15 most recent of 30 sources. Enable JavaScript to search and browse every indexed mention.