Learn ASM
PC Tools
PC Docs

I didn't get my start in the early days of the programming world. That was before my time. But when I was first learning to program (1972), new languages were being discussed and implemented at a pretty fast pace. I remember using Algol 68, Fortran II, Pascal, several flavors of BASIC (of course), PL/I, APL, COBOL, RPG-II, SNOBOL, Lisp 1.5 and InterLisp, as well as many assembly languages, including PDP-8, PDP-11, PDP-10, IBM 1130, 360 BAL, etc. It wasn't until 1978 that I first experienced using C, though, and only then because that's in which much of Unix version 6 was written.

At the time, the language compilers or interpreters each offered certain advantages but also distinct disadvantages. Stack based CPUs were unusual (my first experience with general hardware stacks was with the PDP-11.) The common thread among all programmers and their machines was the use of assembly at least some of the time. It was quite normal that a programmer would learn some assembly language, because every programmer would face tasks requiring it.   It was simply expected. Heck, it was even expected that you'd remember the binary machine language format so that you could "toggle in" the code directly into the machine without an assembler, at all.

A given compiler language standard is much more likely to be found for a variety of machines or microcontrollers, today. Also, the programming field has grown dramatically and computers are found in a great many homes and microcontrollers are present in many, many products, as well. Memory and CPU speeds are both greatly enhanced now.

Just as those changes have taken place, young people now also consider programming as just one of a variety of possible career choices. As an undergrad teacher for a few years, I had university students actually tell me it was "between being an accountant or a programmer," for example. That kind of thinking was extremely rare when I was starting out. You were there because you naturally gravitated to it or it was a natural part of your other interests. For example, my major was physics and computers were a natural outgrowth of that basic interest of mine, since equations and modeling could be effectively done with computers. Programming wasn't chosen merely because it paid well or offered a planned career choice.

Still, when the IBM PC first came onto the scene in 1981, the minimum system only came with 16k RAM and assembly language was still the choice for professional programmers. The BASIC interpreter wasn't really an option. Soon, C would be available, but it would be some time before memory systems and CPU speed would mean that other language options would often be preferred.

The areas where assembly language is used well have changed some and there is no longer an expectation that a programmer know how to program effectively in some assembly language. A programmer can very likely go their entire career without having to deal with it, if they want to make that choice. That doesn't mean assembly isn't alive and well, it just means that the world of programming has grown to such huge proportions now that an entire programming career can completely skirt learning to program in assembly and still be a full, worthwhile endevour. Programming is a very inclusive, wide world today and the types of people finding a career there are more varied themselves, as a result.

Why Assembly?

University computer science courses usually include several classes on computer architecture and assembly language programming, more often in the second year of undergraduate course work. Using assembly language for a short time, even if it is promptly forgotten later, is an important part of learning about computer architectures, because it helps to deepen that understanding through genuine hands-on work. For most students, an abstract discussion of computer architecture alone just isn't enough to get the points clearly across.

But there are lots of other reasons why you might want to learn assembly, than just getting a degree or passing a course. If you work on microcontroller products, you will almost certainly need to know how to program in assembly. If you work on operating systems (such as low level drivers for Windows or other ring-0 code such as VxDs), most compiler tools, or any place where the semantics offered in assembly cannot be met by an available higher level language (such as equal execution time in the 'if' and 'else' code branches), then you will find assembly language valuable. And if you are just interested in knowing how things work inside, you'll want to try your hand at it. I also just think it helps you be a more well-rounded programmer and better able to participate in successful product designs, but that's a bias from my personal experiences.

Why Not Assembly?

Oft-heard complaints about actually using assembly language is that it "takes a lot longer to write" and that "compilers are better than humans" at it. Like better magician acts, there's some truth and fact mixed up in these illusions.

Yes, assembly may take a lot longer to write in some cases. For example, if your application is for prototyping an algorithm to solve some problem and that algorithm is largely mathematical and will go through a number of rapid evolutions as various ideas are attempted on real data then you will find the use of BASIC, C, or FORTRAN equations very handy and more easily modified. Higher level languages often excel at prototyping ideas. And yes, compilers are incredible at certain bookkeeping tasks that would daunt an assembly programmer. But these suggestions aren't the whole programming picture.

I usually spend about 20-30% of my time actually coding up an application. Experienced programmers tend to move increasingly towards carefully negotiating what's really needed in the application and what isn't needed, considering the details, analyzing and documenting the approach for comment and rebuttal, and designing the details. This care taken in the early stages pays off handsomely in the end. If you work similarly, you will find that this analysis and design time works as well for assembly coding as it does for C or BASIC. When you have a well-visualized design, the coding in any language proceeds at a very good pace.  Even in assembly (when you are experienced with it, of course.) So, whether or not it "takes a lot longer to write" will depend. For many applications I personally face, it makes only a small difference one way or another.

But if your projects fit well into the usual "input, process, output" model; are intended to run only on well-featured operating systems; will use virtualized I/O; and have no crucial timing or hardware to deal directly with, chances are you may not need to worry about assembly. Reasonably decent, complex, and full-featured operating systems are much more available now and often virtualize all scarce resources (including CPU time) quite well. Under those circumstances, running in the soft cocoon of a vetted operating system, high level languages make a lot of sense.

So Which Is It?

It's really up to you, honestly.

For those of you who are truly into serious electronic engineering, robotics, or else a general computer/electronics geek like me, you'd do well with some kind of machine programming or assembly language early on. There are important semantic insights from learning assembly language which will carry you well, regardless of where you go. And it is sometimes much easier to learn them without having to climb over the baggage of pre-conceived notions from some higher level languages. Of course, it's never too late to learn assembly. You'll only benefit from it. You can tell if you are a geek like me -- your TV is caked with dust; your lawn so high it's impassable; and you always keep an open technical book on your car's steering wheel as you drive (and read.)

For those of you who are seriously struggling to decide between corporate marketing or computer programming, it won't matter nearly as much. Just focus on what skills the programming marketplace is buying and learn that and only so much of it as they will pay well for. You probably don't need assembly language experience. Don't read anything that you don't have to. Socialize, have regular outdoor barbecues, pool parties, and hot tub get-togethers. Life is indeed short and I'm sure your sparkling TV and trim lawn could use a little more attention, too.

Self Education

If you are at this web site for some reason, chances are you are trying to learn about assembly language on your own.  If so, there's a very long road ahead for those serious about educating themselves beyond the immediate needs of a particular project.  And this is especially true in learning about computer architectures, their machine codes, various assembly languages, compilers and optimizers, operating systems and concurrent programming.

Each piece of good documentation is hard to come by and some of it probably outdated.  For example, important documentation on the front side bus transactions exists in the PPro documents from Intel, but were dropped in their later 32-bit architecture books covering the P II and PIII.  Even when the documentation is kept current (as Intel's manuals tend to be), it is a reference rather than a teaching tool.  Worse, folks who really know this stuff well are hard to come by, too, and no one is likely to have all the time needed to spoon feed you.

Good luck.

Feel free to email me.

Last updated: Sunday, July 11, 2004 11:48