"What You See Is Not What You Execute (WYSINWYX)"

Embedded.com [Which annoyingly refuses to load in Opera.] has posted an article worth reading: When good compilers go bad, or What you see is not what you execute by Paul Anderson and Thomas W. Reps. Also don't miss the comments at the end of the article.

Paul and Thomas cover some interesting examples, where the compiler produces correct but unexpected code, especially in security applications.

To me it seems to come down to writing your own security function's in assembly language.

Alas even writing in assembly language is no guarantee that What You See Is What You Execute (WYSIWYX). Long ago I had an 1805 based project that I was developing using an Avocet Systems assembler.

The assembler generated a correct listing file, so I blamed my own code for days for the project continually crashing. When I'd simplified the code to the point that almost none of it was left, I found that the HEX file being produced was wrong! The HEX file had the high and low bytes swapped in a long jump instruction, just the opposite of what the listing showed! To Avocet's credit they did quickly supply a fix.

In that same 1805 era I also had a "bug" that turned out to really be a bad 1805. The 1805 XOR instruction was broken, but only on certain bit patterns! This is why some safety standards mandate that the execution unit be tested at power on. They then go on to mandate that the system must be operational in under one second. An exhaustive test of today's complex micros is not practical to do in under a second. The Paper Pushers never cease to find ways to make conflicting requirements...

Getting back to the WYSINWYX issue. In a safety application it is always good, and some times required, to look at the generated output in an independent tool. Something like the IDA Pro disassembler.

Why would you want to look at the results in an independent tool?

I ran into a problem with an expensive commercial circuit board program. Somehow I managed to get a big hoking hole in the middle of the board, but neither the layout tool, nor the built-in Gerber viewer showed the problem, because they both used the same rendering engine. After that day I learned to always view my Gerber files in an independent Gerber tool. I've also switched to higher quality Open Source layout tools.