Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Related, somehow: Core War [0].
- My favorite is having an XOR opcode modifying the operand of its next IMUL operand.
Fools QEMU and makes for a good "am I on a VM" logic test.
A function of precalculating XOR operand inadvertly twice at QeMU TLB compute time AFTER retrieval of and toward its cached IMUL operand value.
In short, emulation doing preparation of registers twice (negating XOR)
Now you have a logic test revealing QEMU thru minute differential of IMUL operand value and its different multiplication results.
ROT13, anyone?
Disclaimer: works only on RXW memory page. It is literally a self-modifying code.
by egberts1 - A great resource for any performance deoptimization.by vardump
- what im seeing from this chart is that we should be using the nop instruction for everythingby codeshaunted
- Well the best code is no code. Nop could be second best though.by bee_rider
- Does that mean Chris Domas is ready for his next adventure?by markus_zhang
- Nop should be #1, because it is infinitely slow for what it does. ;)by layer8
- It's a little faster than yep.by hyperhello
- Strategy: nop does nothing. It opens the leaderboard accordingly.
Score: 1 cycles Time: 0 nanoseconds
by mito88 - It increments rip by one.by jooops1
- It'd be really interesting to see whether the winning (losing?) instructions/strategies would be different on other architectures. At least right now the top spot (`fxrstor64` on MMIO, starve PCIe) seems relatively architecture-independent, but maybe something about MMIO ordering rules on e.g. POWER would be different enough to change that -- or perhaps open up new avenues?
I wonder what the actual limit on this `fxrstor64` is right now. If you can stall the PCIe bus for that long, then why not indefinitely? Certainly there's no forward progress guarantee here.
by achierius - I think the idea was to find a long instruction on an ordinary PC. Of course by adding special hardware you can stall things.by inigyou
- This author also has other things like: A compiler that emits only `mov` instructions and another compiler that deliberately messes with the control flow so that, if disassembled, common debuggers will draw symbols like skulls or threats. https://github.com/xoreaxeaxeax/repsychby TomatoCo
- I saw a string of emoji that supposedly when copied to a file and renamed .exe prints out hello when run.by Gibbon1
- He also bruteforced the entire opcode space to find undocumented instructions (sandsifter).by inigyou
- 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.
by thyristan - Page tables are physically addressed, so can't recurse. I assume this thing actually works by causing a page fault on the first instruction of the page fault handler, which is a new instruction.by inigyou
- It says in the rules
> Trapped/emulated/virtualized instructions may only time the trap, not the handler.
But I feel like that 12ms write to an ACPI IO port at current leaderboard position 8 is probably trapping to SMM and being handled there.
by monocasa - Bus cycles can be arbitrarily long on any processor that has memory cycles with a hand shake requiring an ack, with no timeout.
E.g. we can build a board around a MC68000 where we make it lock up forever in a bus cycle, waiting for a DTACK that doesn't arrive.
Some early microprocessors had clocked bus cycles without handshaking. They would put out an address on some address lines and signal some line together with a read/write indication, and then expect the transfer to be completed within some clock cycles. If nothing is attached to the address, they would read whatever values are on the bus, like maybe all 1's if it is an open drain system that requires the transmitting device to pull to ground to indicate zero.
I'd say that kind of thing belongs to a hall of shame; it requires software hacks to interface with anything that can't keep up with the prescribed bus cycle.
by kazinator - Bus cycles can also be arbitrarily long on those microprocessors if they don't use dynamic logic - you can stop the clock.by inigyou
- In general, more complex processors have latency issues, and in some ways modern chips have actually become worse with each design iteration.
https://en.wikipedia.org/wiki/Metastability_(electronics)
Ultimately... failure modes must arise because naive gate design simulation models can't determine issues in a computationally feasible time frame.
The consequences of "fixing" CDC prone design flaws makes a processor many times slower (8 to 16 times slower on my dumb attempt), and develops weird alien design features very different from Von Neumann architectures.
This is why we can't have nice things. =3
by Joel_Mckay - > E.g. we can build a board around a MC68000 where we make it lock up forever in a bus cycle, waiting for a DTACK that doesn't arrive.
IIRC, early 68k Macs had processor upgrades hooked onto the 68k bus and did exactly this - an early boot driver run by the “actual” CPU coordinated handoff with the expansion CPU’s bootstrap ROM.
by nxobject - Related, and linked in the readme: https://github.com/xoreaxeaxeax/smiiiiiiiiiiiiiiii (using the slow instructions to break SMI)by Retr0id
- I wish they would just explain it in normal terms instead of this nasty LLM "engaging blog post" styleby jonathrg
- Yeh that's a really nice one; I don't see anything in that suggesting it's been fixed (or even reported?)by trebligdivad