"Atomic" Bugs

Before I get deep into this topic, I should give you a backdrop of a hypothetical. Let's say you are designing a program for a CPU that is Big-Endian, but it turns out that the CPU is Little-Endian. How would the data that's being processed be affected? For the case of sound drivers, the data being outputted through the speakers will sound muffled with audio artifacts. Case in point, Tetris: The Grandmaster.

The first video has the data stored as big-endian.

The second video takes the sample data, then byteswaps them to little-endian.

The reason for this is that the sound program is targeting the Z80, but the composers forgot to account for how it would process the samples resulting in the first video. This is one way of how the architecture of the CPU can ultimately change how a program functions.

Now that was a simple comparison of Endianness, but what about RISC vs. CISC CPUs? This is a huge thing to account for with ARM making its presence on desktops and laptops vs. the traditional x86 machine. Due to having different instructions, the source code can be the same yet their compilation can lead to wildly different results.

Recently, there was a bug that was fixed in MAME pertaining to the timer for the C140 PCM chip. For a while, some people knew the problem but don't know where to look. The smoking gun was when someone was running Windows on ARM, and noticed that the music was playing erratically.

I thought this could be the case for a bug in my Senior Design project and the clipboard. Someone was able to do some tests with an Intel Mac, and it turns out it was Google Chrome being cautious on letting us doing direct writes to the system clipboard. In order to fix it, we would have to change how we interface with the API. A nice takeaway from this situation is my awareness of DWARF and Google developing a debugger with it, too bad it doesn't interface with Rust code well. Although, I was this close to debugging WebAssembly. Oh well, I'll save it for another time.

The idea for this article came from a seminar done by Daniel Spiewak documenting his experience of hunting down a bug in the JVM. The jist of it is that software engineers need to start to account for different architectures in their tests to ensure that their software functions consistently across them.

Finally, if you're interested in the C140 and willing to translate through a lot of Japanese, then I highly recommend reading these articles talking about its development and how it shaped the design for their sound driver, Quattro.