The time the x86 emulator team found code so bad that they fixed it during emulation - The Old New Thing
devblogs.microsoft.com · 332 words · saved by 1 readers
Offensive content in the eyes of a software engineer.
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…
saved by
related reading
- abseil / Performance Hintsabseil.io
- Things You Should Never Do, Part I – Joel on Softwarejoelonsoftware.com
- What Every Programmer Should Know About Memorypeople.freebsd.org
- The hunt for a faster syscall trap - The Old New Thingdevblogs.microsoft.com
- The Curse of Knowing How, or; Fixing Everything | Blognotashelf.dev
- Astra for Coding: Why Are We Doing This Again?lucumr.pocoo.org
- Ken Shirriff's blogrighto.com
- research!rsc: Hardware Memory Models (Memory Models, Part 1)research.swtch.com
- A Bunch of Programming Advice I'd Give To Myself 15 Years Ago | Marcus' Blogmbuffett.com
- GitHub - xoreaxeaxeax/asm-hall-of-shame: Racing to the bottom of CPU performancegithub.com
- Accidentally Quadraticaccidentallyquadratic.tumblr.com
- Who ordered memory fences on an x86? | Bartosz Milewski's Programming Cafebartoszmilewski.com