Why Learning Assembly Language Is Still Good

nickirelan writes "Why Learning Assembly Language Is Still a Good Idea by Randall Hyde -- Randall Hyde makes his case for why learning assembly language is still relevant today. The key, says Randall, is to learn how to efficiently implement an application, and the best implementations are written by those who've mastered assembly language. Randall is the author of Write Great Code (from No Starch Press)."

Comments

As somebody who has done DSP algorithms

[earthforce_1]

Assembly language will always be needed to optimize certain types of algorithms, that don't translate efficiently into C. Try writing a FFT algorithm on C using a DSP, and compare it to what can be done in native assembly. The difference can be an order of magnitude or more. Some processors have special purpose modulo registers and addressing modes (such as bit reverse) that don't translate well into C, at least not without extending the language. Fixed point arithmatic operations are not supported in ANSI C either, but are a common feature on special purpose processors.

For low power/embedded applications, efficiency makes sense as well. Every CPU cycle wasted chips away at battery power. A more efficient algorithm means a smaller ROM size, and the CPU can either be clocked slower (can use cheaper memory and/or CPU) or put into a halted state when it isn't needed. (longer battery life) Coding small ISRs in assembly makes sense as well, as C compilers often must make worst case assumptions about saving processor context.

That being said, only a fool would try and re-write printf or cout in assembly, if they have a C/C++ compiler handy. Hand optimization is best used as a silver bullet, for the most computationally intensive or critical functions.

Re:Which Platforms?

[Archeopteryx]

I would start with an emulated 8-bit microprocessor or microcontroller, such as the Z-8 or the 68HC908. This way they can run the emulation on a platform they already have, and such devices, embedded within ASICs are the most likely target for a pure assembly effort anyway.

Just a couple of years ago I did a fairly large 68HC908 application for a housekeeping processor entirely in assembler.

Re:don't bother........

[johnnyb]

You need to know the low-level stuff for a few reasons:

1) You are a programmer, and knowing how the computer functions is your job

2) Many of the high-level constructs are better understood when you know what it is they are trying to abstract. It will also keep you from doing stupid things like making everything in java a BigNum or whatever that is.

3) The idea of references and pointers are a lot more fuzzy for programmers who never learned assembly language. The difference between a pointer and a value is harder to grasp.

4) Debugging is a lot easier when you know assembly language, because you know how the parts fit together. You understand what a calling convention is, you understand how memory mapping works, you understand how the stack works - you just can see the whole picture of how the machine is processing your data.

There's even some optimizations that you can do still in higher-level languages that you get from knowing assembly language. For example, in C, the first member of a struct is accessed faster because the compiler can just do straight indirect addressing rather than base pointer addressing. It might also convince you to rewrite your loops so they have a better chance of fitting entirely into the instruction cache. But even without these things, knowing assembly language is useful for the four reasons I outlined above. It's also useful for people who are having trouble learning to code, because it forces them to think on a much more exacting, step-by-step, concrete level.

JIT?

[magnum3065]

I suggest you watch this presentation on the Psyco just-in-time compiler for Python and do some research on the Transmeta Crusoe processor to learn about run-time optimization.

Re:Debugging

[prisonernumber7]

This is called a heisenbug, in case you are wondering. They occur mostly due to a smashed stack and are indeed damn hard to track.

You can of course use assembly to track the bug, but I myself find that tedious. If you are programming in plain C (and not C++), you can use lint, a tool that evaluates sourcecode, very often. When lint reports no more possible problems you are done.

If you happen to use C++ you'll probably have to shell out big bucks for a linter or be out of luck because there are only commercial linters available.

Tho, that's why I always have a Linux system with valgrind, which is amongst other things a memory debugging tool, available on it (unfortunately valgrind does not work on any of the BSDs). Valgrind will scream and give a stack backtrace when your program does something wrong - be it an off-by-one error, be it memory being read uninitialized or whaterver. A truly genial tool.