[Greg McKaskle]

Interesting topic.

I prefer to recruit from CS departments that teaches assembly in at least one class. I think it is useful, perhaps even necessary, for truly understanding computer architectures. On the other hand, once hired, productivity is important. Higher level languages were invented for good reason, and in my career, I've replaced more assembly than I've written.

For instance, in an early project, I was tasked with rewriting 100 pages of assembly code macros for 68k so that it would run on a 386. I read through the assembly code macros for days looking for a strategy to map the two architectures. The code was primarily doing floating point, and it was dealing with nasty stuff -- overflows, underflows, extended formats, double formats, single formats, integers, etc. I was still struggling to determine how I'd deal with the FP register differences when I talked with my mentor and we discussed why it was in assembly in the first place. Over the next few days, I wrote six pages of C code that used macros and other techniques to keep efficiency. It replaced the functionality of the assembly code, was portable not only to the 68k and x86, but also worked on SPARC. For performance reasons, it called about fifty lines of assembly that identified special float values such as infinities and NANs. Would the assembly code have been more efficient? I'll never know, because NI wouldn't want to pay me for the several months it would have taken me to write and debug it. Later it would also have taken several months more to write it for SPARC. And then there was the PA-RISC processor for HP. More time.

In all, that single decision probably saved the company half a man-year of labor costs with no impact on runtime efficiency. Even better, the code was pretty easy to read and test. Fifteen years later, the C macros were rewritten into C++ templates and again, the efficiency was maintained.

My point? Learn your tools. Explore assembly by writing a small function that you call from C++. Perhaps start with a routine to average sensor readings or something small. Work your way up to a PID. That will be more of a challenge than you may think. Be sure to compare the results to the C version. If you love it and you can show efficiency of the finished code and your ability to write it, keep going. But if you find yourself spending lots of time writing many lines of buggy assembly code, you will have discovered why some extremely bright individuals built higher level languages.

Enjoy the journey.

Greg McKaskle