[Greg McKaskle]

Learning assembly and low-level computer architecture are good things. Putting your experiments on your teams robots -- maybe not.

Assembly programming is a very unforgiving task, and is best done with a net. My CS degree was a few years back, but they still required an assembly course. It was done completely virtual, on a mainframe, because your program would crash about 90% of the time. Since it was virtual, the "processor" was frozen so that you could examine the remains and determine where you went wrong, modify code, and run the experiment again. Even with the help of good tools such as this, it was a painful reminder of just how low-level and complex computers are.

The good thing about that experience is that from time to time, I need to look under the covers and try to understand a bug, an optimization, etc. and being able to grok the assembly and low-level parts of the computer is useful. The rest of the time it would only slow me down by about 100x.

Once you have a good PPC assembly reference and understand the basics of the architecture, I'm pretty sure that you can run your C++ code in vxWorks, hit a breakpoint, show the registers, the stack, and the disassembly. Even better, some environments show you the mixed view of your code -- a line of C and the assembly for that line. This will allow you to see how the compiler produces assembly, learn its tricks, and do it much faster than starting from scratch. It is informative to look at array indexing code, function calls, loops, and other high-level structures that make you productive. It is also informative to intentionally put some common bugs into your code and step through them in assembly to better understand what they cause the computer to do.

Greg McKaskle