The time the x86 emulator team found code so bad that they fixed it during emulation

Lobsters Hottest News

Summary

A story from a Windows x86 emulator team about encountering a program with a fully unrolled 64KB initialization loop (65,536 instructions) and adding a special optimization to replace it with a tight loop.

<p><a href="https://lobste.rs/s/mjkp4m/time_x86_emulator_team_found_code_so_bad">Comments</a></p>
Original Article
View Cached Full Text

Cached at: 06/16/26, 11:32 AM

# The time the x86 emulator team found code so bad that they fixed it during emulation - The Old New Thing Source: [https://devblogs.microsoft.com/oldnewthing/20260615-00?p=112419](https://devblogs.microsoft.com/oldnewthing/20260615-00?p=112419) During an exchange of war stories, a colleague of mine told one from back in the days when Windows included a processor emulator for x86\-32 on systems that natively ran some other processor\. \(This has happened many times\. And no, I don’t know which processor this particular story applied to\.\) This particular emulator employed binary translation, generating native code to perform the equivalent operations of the original x86\-32 code\. This offered a significant performance improvement over emulation via interpreter\. You can imagine that x86\-32 is just a bytecode, and the emulator is a JIT compiler\. Anyway, my colleague found that there was one program that needed to allocate around 64KB of memory on the stack and initialize it\. The standard way of doing this is to[perform a stack probe to ensure that 64KB of memory is available](https://devblogs.microsoft.com/oldnewthing/20260311-00/?p=112134), then subtracting 65536 from the stack pointer, and then initializing the memory in a small, tight loop\. But using a loop to initialize the memory was too mundane for whatever compiler was used to compile this code\. Instead of generating a loop to initialize each byte of the buffer, the compiler “optimized” the code by unrolling the loop into 65,536 individual “write byte to memory” instructions, each 4 bytes long\. All in all, it took this program 256 kilobytes of code to initialize 64 kilobytes of data\. This offended the team so much that they added special code to the translator to detect this horrible function and replace it with the equivalent tight loop\. ### Category ### Topics ## Author ![Raymond Chen](https://devblogs.microsoft.com/oldnewthing/wp-content/uploads/sites/38/2019/02/RaymondChen_5in-150x150.jpg) Raymond has been involved in the evolution of Windows for more than 30 years\. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie\-jeebies\. The Web site spawned a book, coincidentally also titled The Old New Thing \(Addison Wesley 2007\)\. He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information\.

Similar Articles

Emulator Debugging: Area 5150's Lake Effect

Lobsters Hottest

The article details the debugging process for the 'Lake' effect in the Area5150 demo on the MartyPC emulator, explaining the need for a title-specific hack and the subsequent fix using bus sniffing and dynamic clocking to achieve cycle-accurate CGA emulation.

Making stinkarm stink less, or more?

Hacker News Top

An update on improving a minimal ARMv7 emulator, focusing on optimizing memory translation from complex B-tree mapping to a simplified 4 GiB slab approach for efficiency.

80386 Early Start Memory Access

Hacker News Top

The article explains the Early Start memory access technique in Intel's 80386, which hides memory latency by overlapping address generation with the previous instruction's last cycle. It describes the implementation of this technique in the z386 FPGA core, achieving ao486-class performance and a 39% improvement in Doom FPS.