One thing I've noticed from a lot of people is the assumption that the tools they use are at fault for the errors they observe. While this can indeed be the case (one only has to look at the bugs list of any major project for evidence), the first, second, and third rules of debugging are to assume that the tools are perfect until all other possibilities are disproven as the source(s) of the error(s). One example relevant to the TI is that of OS v. 2.5x, an OS often cited as the cause of many inexplicable errors. However, it is well known that the vast majority of errors are user errors, not code errors, especially in any prominent piece of code. As comfortable as it is to blame the tools, those same tools are debugged very thoroughly for the simple reason that bugs are often far more important in a tool than in a random program. In general, important programs such as Operating Systems, Compilers and Interpreters¹ are among the least buggy programs available by sheer necessity. Before claiming an error is caused by any of the above, please stop and consider whether the errors are valid bugs. Spend time looking at the documentation. Check previous bug reports and your own code carefully. Major bugs in tools are extremely rare, highly publicized, and almost always well documented.


¹: There is almost never a good reason to assume a hardware bug in commercial hardware. Don't do it without extremely strong evidence to back that claim (such as integer addition of 1 and 1 producing 3, in which case you should still be checking your display and register loading routines first).

SDCC, in the 3.0.0 version and in the optralloc branch, defies that statement by making up opcodes, using a jr when it is clearly trying to jump by a 16 bit number, or just failing to manage the stack... But that's just me and mah buggy OS, which somehow runs.

Most of the time, the compiler is often the reference implementation of a language. So it's right because the author decided it.