256KB of code to zero 64KB of memory, fixed mid-emulation

When the emulator decides your code is too embarrassing to run

The usual job of a binary translator is faithful reproduction: run the foreign instructions exactly as written, just on a different CPU. Raymond Chen's latest Old New Thing describes the rare moment a team broke that rule because the code was too awful to tolerate.

The math that makes you wince

A program needed to allocate roughly 64KB on the stack and zero it. The standard recipe is a stack probe, one subtraction from the stack pointer, then a tight initialization loop. This compiler instead fully unrolled the loop into 65,536 individual write-byte instructions. At 4 bytes each, that is 256 kilobytes of machine code to initialize 64 kilobytes of data. Chen, who admits "I don't know which processor this particular story applied to," recounts that the emulator team added detection logic: when the translator recognized this exact monstrous function, it replaced the 256KB sequence with the compact loop the compiler should have written, rolling the loop back up at translation time.

Insiders confirm it wasn't a one-off

The pattern of compatibility layers silently patching broken software runs deep, and someone who'd lived it said so in the thread:

"People from Transmeta told me stories about how their translators were full of special case optimizations to fix horrors they discovered in Microsoft Windows itself." — a commenter with 24k karma recounting Transmeta engineers

A second engineer offered a field example of the same class of disaster: a game that called fread(data, 1, 65536, fptr) instead of fread(data, 65536, 1, fptr), turning one read into 65,000 single-byte reads and stretching a 15-second load into minutes once his on-demand layer hooked the OS calls.

Maybe the ugly code was the fast code

The most useful pushback questioned the whole premise of "bad." Loop unrolling exists precisely to skip branch and counter overhead:

"On the surface 256k to init less does seem silly, but what if it was faster?" — a commenter challenging the article's missing why

Another reframed the fix as "un-unrolling a loop" rather than a bug repair. That is the real lesson buried under the gross-out number: the emulator didn't correct a logic error, it overrode a space-time tradeoff someone made on purpose, on hardware where it may have won. "Bad code" sometimes just means code optimized for a machine you're no longer running on.