Over the last few months I've been pondering the use of assembly language. After chatting to a variety of different people, I have the impression that the world is split between "application-level-type" programmers (who wouldn't know an assembly language routine if it crawled up their trouser leg and bit them in an unfortunate place) and "embedded-systems-type" programmers (who would know an assembly language routine if it... you get my drift).
Actually, in the not-so-distant past when I was a young engineer (well, maybe that is in the distant past now), application-level-programmers were well-versed in both assembly code and higher-level languages like C. By comparison, although we all know what assembly code is, relatively few of the younger application-level-programmers seem to have actually used it in anger; instead they float around playing with programming languages like C/C++ and scripting languages like VBScript and Python.
In fact, when I ask about using assembly language, many of these folks screw their noses up as though they had just smelled something unpleasant. The overall impression is that assembly is cumbersome, error-prone, time-consuming, and – generally speaking – a "pain in the rear end" to use. Well, yes, I suppose so, but it can also offer advantages, because you are down in the inner machinations of the machine where you can control what happens in exquisite (sometimes excruciating) detail.
Truth to tell, I actually find programming in assembly language to be a lot of fun. I recently wrote a simply monitor program in my own simple assembly language (for use on my Virtual DIY Calculator) that ended up occupying around 700 bytes. Also, I've been playing with a variety of bit-manipulation puzzles and posers like counting the number of 1s in a byte using the fewest number of instructions (you can find the code and documentation on both of these topics on the Programs and Routines page of my DIY Calculator website). And I'm not alone – as I pen these words, someone is creating a simple BASIC Interpreter in my assembly language for use with the DIY Calculator.
So what I would like to do would be to document the pros, cons, and reasons for using assembly language. My own thoughts (plus ideas from a variety of sources) are as shown below, but I would be delighted to hear if you agree, disagree, or have some additional thoughts to "throw into the pot":
- You can hand-craft code that's really fast.
- You can hand-craft code that consumes relatively little memory.
- You have total control over what's going on.
- Creating assembly code is time-consuming.
- Creating assembly code is error-prone.
- Reasons for knowing and/or using assembly language
- Folks writing code for Digital Signal Processors (DSPs) often start off capturing the algorithms in C; then they profile the application to determine any "hot-spots" that need "tweaking" in terms of performance-power-timing and recode these portions of the code in assembly.
- Low-level drivers or other embedded applications that require the ultimate in performance may contain portions written in assembly language.
- You may be maintaining an old "legacy" application that contains functions written in assembly language.
- You are creating a compiler that takes a high-level language and translates it into assembly that will subsequently be translated into machine code. In this case you aren't writing the assembly language, but you do have to have an intimate understanding of it.
- You are reverse-engineering an application (doubtless for totally legal reasons) for which you do not have access to the source code.
- You are forced to learn it in one of your college courses.
Questions? Comments? Feel free to email me – Clive "Max" Maxfield – at firstname.lastname@example.org). And, of course, if you haven't already done so, don't forget to Sign Up for our weekly Programmable Logic DesignLine Newsletter