Is Assembly Language Obsolete?

2/25/2008 1:22 PM EST

I agree completely. To develop a high-volume, low-margin product (as embedded systems often are) requires at least understanding assembly. Understanding the assembly not only gives insights into the processor's architecture, but also the performance of the SW.

For DSP programming, it is routine to examine the compiler's assembly for cycle-sensitive code to see how optimal the assembly is, and what is limiting the compiler from further optimizations.
Also, by looking at the assembly a good judgement can be made for stack requirements, rather than simply over-allocating an obscene amount of stack memory.

These reductions of cycle and memory requirements decrease product cost, which is usually a big deal for embedded systems.

With a good compiler, programming in assembly should be rarely necessary. However, understanding assembly is still vital.

2/25/2008 1:46 PM EST

Need your routine to take exactly 'n' clock cycles, or ensure it takes less than 'p' clock cycles? Well, you better be writing it in assembly.

Does your entire software program need to fit within 1k of code space? Does it need to use only 24 bytes of RAM? You better be writing it in assembly.

Code size, data size, and cycle count is where assembly will reign. When some implements a compiler where there's a known mapping betwen source-line-of-code and machine codes, then assembly may fall out of use.

Wait, there is already one: assembly!

2/25/2008 10:17 PM EST

I agree totally with you. It is imperative that assembly language be taught and re-introduced if ever.

In my short career I have come across several engineers who code and implement several items, without due regard to the underlying OS / architecture / hardware. When I talk with them, most of them have no idea what assembly programming is. They dont even think about software footprint and indirectly, optimized coding.

I guess when Java and all these other GUI Driven IDE's were created, they made life simple for most engineers but have somehow shielded them from certain items I deem important in the embedded engineering profession.

My take, no way assembly is going to be obsolete :)

2/28/2008 2:49 AM EST

Consider the Intel 8051. Sure, it's not a very interesting architecture and Intel did finally pull the plug on it. However, there are still 20 or 30 manufacturers churning out their 8051 versions. The same thing goes for other old architectures. WDC still makes 6502s, Zilog makes Z80s...

So, the 8051 is not going to go anywhere and neither are the millions (or billions?) of lines of assembly code written for it. That stuff needs maintaining and new versions will be based on the old. Nobody is going to suddenly reimplement all that in C.

2/28/2008 4:02 AM EST

The C compilers are certainly quite efficient today, but the C/C++ language itself has some limits. For example, on 16 bit processors C can handle 8bit, 16bit and 32bit data and that is all. But the processors offer 16 x 16 to 32 bit and many other functions, which are directly inaccessible from C. Also, it may be quite an advantage to work with 48bit or 64bit integers instead of using time consuming floating point functions. Todays processors often don't have all the instruments for extending precision (for example compare with carry instruction), but still it can be very advantegeous to write optimized functions for manipulating specific data formats in assembly language. Most floating point libraries for FPU-less processor are written this way, because C language just doesn't have direct access to carry, overflow, to specific instructions designed for floating point operation support etc.

Last, but not least, there are errors even in the C compilers, more optimization usually means more risc. And the assembly language is the only way to find it and fix it.

2/28/2008 8:02 AM EST

I too am in agreement with the article here. At WattStopper i was one of the people who stongly pushes the usage of C, because all we were doing was assembly. But i still code in assembly and it is here to stay. A firmware programmer needs to understand how the registers are being used, and what is going on at the machine-code-level.
Regards, Alexandre Debernard

2/28/2008 8:27 AM EST

I agree 100%. I'm currently supporting products written in assembly.

There are some things that require assembly as there is know way I'm aware of to do them in another language.
A couple that come to mind are enable and disable interrupt and read modify write.

Boot code and self test code almost always contains some assembly.

2/28/2008 8:49 AM EST

Completely agree with you Jack. Assembly language plays a vital role in systems programming. I remember a quote by Joel Spolsky(its abt a book - "Pragramming from the ground up") -
"Trying to be a programmer without understanding how a CPU works is like trying to practice medicine without learning anatomy. Sure, you can have limited success curing patients with medical advice gleaned from Google, but on the whole you're going to be a pretty bad doctor. For those who missed out on learning assembly language, I highly recommend working through this book, even if you'll never program in assembly again. I promise that all kinds of lights will go on in your head and you'll be a vastly better programmer."

Many times we need to use 'in line assembly' for doing specific cpu intesive tasks in high level languages..the awareness of assembly language programming surely helps the programmer to think from the machine point of view and that can change the design of his code, which will only make his code far more better and much more efficient and machine friendly.

2/28/2008 12:24 PM EST

I agree that an understanding of assembly, and the knowledge of the processor architecture that must accompany that understanding creates a "model" of expected system behavior in the mind of the developer. The model in our head is what we play our designs against in the concept stages. The model is also what we use to find the defects in our products - when the observed behavior does not match our model.

A fun and very low priced tool to develop an understanding of assembly code and a bit of embedded design is the "Computer Science Lab" by John Kopplin. (www.computersciencelab.com) I bought it out of curiosity after reading Jack Ganssle's review a couple years ago. It gives a good "hands on" tutorial on the 8051, along with C and C++. The included Illustrated History of Computers is very interesting for your inner (and outer) geek.

2/28/2008 1:10 PM EST

Well based on the creative names ("MemoryLeak", what a great name!)of the responses from your readers I would say these are the folks who are really doing the work out there, and they seem to all agree (as do I) that assembly is a necessity, depending upon the processor sometimes even a pleasant one.

This reminds me of when my son took a VB class in college, he started asking me all sorts of odd questions based upon what the "professor" had told him. These assumptions about the underlying structure of a computer where all from a VB perspective, and totally wrong! Reminded me of the story of the blind men with the elephant.
I immediately pulled up a current project's schematic and started from there, diving into the chips internal properties and how they related to the outside world. It was amazing how rapidly he then understood what was really going on with the software. When you really want to understand what you are working on, take it to the hardware level and then climb back up to your lofty perch. Understanding is "bottom-up", design is "top-down"!

My personal belief is that all entry level computer courses should start with a KIM board (circa: 1970) and start training from there!
If you can program using a hex keypad, you might just make a decent software engineer!

I do take exception to your statement:
"Complex processors with deep pipelines give the edge to compilers which can optimize instruction ordering far more efficiently than a human."
Faster, sure. Better, no way!
Which tool chains are you using that can code assembly better than a talented S/W Engineer?
My experience is that turning on the compiler's optimizer is just a request for more bugs in the generated code! The parts of the code that need to be optimized I will do by hand thank you.
Am I alone in this assumption?

2/28/2008 3:40 PM EST

I got some AVR code from a customer written in assembly, and it was not working.
700 bytes running on an ATtiny13.
Rewrote in IAR C, analyzed the usage of global variables, and optimized the most frequently used variables into CPU registers.
Replaced two state machines with one state machine with an if statement.
Obviously, assembly language made the programmer lose control of the structure
of the program.

Resulting code was ~400 bytes.

2/28/2008 6:42 PM EST

I suppose ... it depends on the following:
- application
- environmental constraints
- managerial tastes
Let us throw the Way-back machine a mere decade ago, (1998, thereabouts), and one will see most embedded systems being programmed using the 'C' language. Now, 10 years later, one will see most embedded systems being programmed using ... 'C' again!. I can say if we fast forward another 10 years, we will see most embedded systems being programmed using ... what else? 'C'. That is not to say that C++ is making inroads. There are a lot of projects out there with embedded GUI's and embedded Linux that are benefitting from a cadre of engineers that are using C++ for embedded.

But alas, more and more, my clients are insisting that we engineers stay away from assembler. That is unless we are working on DSP projects. But DSP's are different from microprocessors no? Today, most of my assembler expertise is used in assisting other engineers determine why Linux, Nucleus, Thread-X or other OS has just thrown an exception fault ... that and reading the post mortem analyzer to determine where the resource leak or faulty pointer originated from.

That is about all!

3/2/2008 4:23 PM EST

All great comments. I'm glad to see that the general view is validated in such a broad audience. That is, it's not that assembly language is dead - just that its use has (and will continue to be) decreased over time - directly as a result of improvements in compilers (and complexities in architectures). Both of those forces make it harder and harder for manually generated code to beat a compiler. Plus, it simply takes longer to create (and maintain!) high efficiency assembly code.

There is an exact parallel between assembly language programming and gate-level chip design. Neither have ceased to exist, but both have become necessary in fewer and fewer instances...

Most importantly (and this is echo'd above, too), is understanding a given processor's architecture, and the mapping algorithms that are used by the compiler. As each is understood better by the software developer, the efficiency of C code will continue to improve (and continue to make assembly coding less necessary to meet performance or code size requirements).