Most typical programmers, when encountered a buggy behavior in their code, often try to diagnose it assuming the compiler is correct (as least intially). That should be the right approach for most programmers. However, being a compiler writer, I very often look at the assembly and start from there - and that helps me spot problems faster than others.
Today was no different - some user had a problem, and it turned out to be a compiler bug but everybody was trying to diagnose it from the higher-level. Given enough time, I have no doubt they would have found the same problem, but different perspective certainly helps (and saves time too!).
This "seeing-everything-through-assembly" approach is fairly robust (at least you won't get mislead by the compiler errors - IMNSHO "being mislead" is the biggest time killer in any debugging effort) but not fool-proof - sometimes, every once in a while, a hardware bug or a kernel bug can bite you :( Even then, you're well equipped to diagnose such a bug if you're looking at the assembly level.
I know, the assembly programmers are a dying breed - I often hear that nowadays some CS students don't even know the assembly. But let me tell you that it could be very useful to know your assembly (whichever processor you're using). At least that was the case for me today :)
Subscribe to:
Post Comments (Atom)
1 comment:
...and I'm debugging hardwares. :(
Post a Comment