ONLamp.com
oreilly.comSafari Books Online.Conferences.

advertisement


Why Learning Assembly Language Is Still a Good Idea
Pages: 1, 2

Assembly Isn't Dead

Assembly language, of course, developed a very bad reputation throughout the 1990s. Advances in compiler technology, improved CPU performance, and the "software crisis" all conspired to suggest that assembly language was a "dead" language that was no longer needed. As assembly language was a bit more difficult to learn than traditional high-level programming languages, students (and instructors!) gladly embraced this brave new high-level world, abandoning difficult-to-learn assembly in favor of higher and higher level languages.



The only problem with the demise of assembly language is that as its popularity waned, so did the percentage of programmers who understood the low-level ramifications of the code they were writing. Those programmers who were claiming that assembly language was dead already knew how to think in assembly language and how to apply that low-level thinking to their high-level code; in effect, enjoying the benefits of assembly language while writing high-level language code. However, as new programmers worked their way into the system, without the benefits of having written several applications in assembly, the efficiency of software applications began to decline.

Though it would be foolish to start claiming that programmers should begin writing commercial applications in assembly language, it is clear today that the demise of assembly language's popularity has had a big impact on the efficiency of modern software. To reverse this trend, one of two things must happen: programmers must once again begin studying assembly language, or they must somehow pick up this low-level programming knowledge some other way.

Learning assembly language still remains the best way to learn the basic organization of the underlying machine. Those programmers who take the effort to master assembly language become some of the very best high-level language programmers around. Their ability to choose appropriate high-level constructs to produce efficient code, their ability to read disassembled high-level language code and detect heinous bugs in a system, and their understanding of how the whole system operates elevates them to near legendary status among their peers. These are the programmers everyone goes to when they have questions how to implement something. These are the engineers who garner the respect of everyone around them. They are the ones other programmers want to emulate. These are the programmers who write great code.

If knowing assembly language helps make programmers great, a obvious question is "Why don't more programmers learn assembly language?" Part of the problem is prejudice: many college and university instructors that teach assembly programming begin their course with a statement like, "No one really needs to know this stuff, and you'll never use it, but it is required by this program so we've got to struggle through the next several weeks studying this material." After four years of this type of attitude from their instructors, it's no surprise that students really want nothing whatsoever at all to do with assembly language programming.

Still, once it becomes obvious to a coder that the truly great programmers are the ones who've mastered assembly language programming, you might ask why more programmers don't pick up this valuable knowledge. The only problem is that, traditionally, most programmers have found it difficult to master assembly language. Assembly is radically different than most high-level languages, so learning assembly language is almost as much work as learning programming from scratch.

To someone attempting to learn assembly, it often seems as though none of their past programming experience is of any help. All too often, an engineer learning assembly becomes frustrated with the fact that they know how to achieve a goal in a high-level language but they cannot figure out how to achieve the same thing in assembly. For many programmers, switching from "thinking in a high-level language" to "thinking in an assembly language" becomes an insurmountable problem.

O'Reilly Open Source Convention.

As an instructor teaching assembly language for over a decade at the University of California, I was quite aware of the problems students have making the transition from the high- level programming paradigm to the low-level programming paradigm.

In the early 1990s, Microsoft provided a solution with the introduction of the Microsoft Macro Assembler (MASM) v6.0 -- the inclusion of high-level control structures in an assembly language translator. While these new statements are definitely not true assembly language, they do provide a nice transition path from traditional, imperative, high-level programming languages to assembly. A programmer can continue to use statements like IF, WHILE, and FOR while learning other aspects of assembly language programs. This lets the programmer learn assembly language programming in graduated steps rather than having to make the plunge all at once.

Master Low-Level Statements

Of course, a programmer cannot truly call themselves an assembly language programmer until they've mastered the equivalent low-level statements. Nevertheless, these high-level control structures provide an excellent bridge between high-level languages and assembly language, allowing the student to leverage their existing high-level programming knowledge to learn assembly language. Alas, there are few, if any, appropriate textbooks that teach assembly language programming using this high-level to low-level approach using the high-level control structures that MASM provides.

Another problem with the high-level to low-level transition is that most high-level languages provide large libraries of routines to handle mundane tasks such as input/output, numeric conversions, and string operations. A big problem that beginning assembly programmers face is that they typically need the ability to input and output numeric quantities or do numeric-to-string conversions (and vice versa) in order to write and test very simple programs. Unfortunately, most assembly language development systems leave it up to the programmer to provide this functionality for their applications. This presents a Catch-22 situation: it is difficult to learn assembly language without these functions, but you can't really write such functions until you learn assembly language.

These roadblocks effectively prevent all but the most determined programmers from mastering assembly language. As such, throughout the 1990s and early 2000s the use of assembly language continued to wane. Seeing the decline in software efficiency and quality that seemed to track the decline of the use of assembly language, I set out on a crusade in the mid-1990s to encourage programmers to learn assembly language programming.

The first milestone I achieved was the release in the mid-1990s of the electronic edition of The Art of Assembly Language. This book, along with the use of the accompanying UCR Standard Library for 80x86 Language Programmers, reduced the effort needed to learn assembly language programming. Tens of thousands of programmers have learned assembly language programming using this textbook and the complementary set of library routines.

The only problem with the electronic edition of The Art of Assembly Language and the UCR Standard Library for 80x86 Assembly Language Programmers is that they were almost obsolete as soon as they appeared on the Internet because they taught the reader how to create 16-bit DOS applications (their release almost corresponded with the release of Windows 95, which was one of the last nails in the 16-bit programming coffin).

Still on the crusade, I started to work on a brand-new, high-level assembler (HLA, the High-Level Assembler), a new version of The Art of Assembly Language, and a new, 32-bit, HLA-based set of library routines. This effort culminated with the release of the published edition of The Art of Assembly (AoA) in 2003. To date, thousands and thousands of programmers have enthusiastically embraced this new way of learning assembly language using AoA, HLA, and the HLA Standard Library.

Though The Art of Assembly Language and HLA are increasing the ranks of assembly language programmers every day, the solution they provide is for the next generation of programmers.

What about current programmers who've missed the opportunity to learn assembly language while in school and master the concepts of machine organization before the realities of project schedules rob them of the time needed to develop the necessary expertise to write great code? The question is, "Can machine organization be effectively taught to professional programmers without simultaneously teaching assembly language?"

While it is fairly clear that learning assembly language is the best advice I can give anyone who is interested in writing great, efficient code, I am also convinced that someone can study the subject of machine organization sans assembly and still learn how to write better code. Perhaps their code won't be quite as good as the programmer who has mastered assembly language, but it will be better than the software they've written devoid of this knowledge.

Most importantly, while it is difficult to sell the idea of learning assembly language to the current generation of programmers (two decades of anti-assembly propaganda have assured this), most programmers realize that if they just "learned a little more about how the underlying hardware works" they would be able to write better code. So what is needed is a set of materials that teach data representation, memory organization, elements of computer architecture, how input/output operates, and the correspondence between high-level programming language statements.

That is, teach them all the things that they'd have to learn when learning assembly language, with the single exception of mastering the assembly language programming paradigm. Recently, I've begun to focus on this group, working on books like Write Great Code, Volume One: Understanding the Machine, a book on machine organization that doesn't specifically teach assembly language programming. While someone studying machine organization might not write code as great as someone who takes the time to master assembly language, my hope is that those who would never consider learning assembly language might be willing to pick up a book like Write Great Code and learn to write better code, if not totally great code.

Conclusion

To write great code requires one to write efficient code. Writing efficient code requires good algorithm choices and a good implementation of those algorithms. The best implementations are going to be written by those who've mastered assembly language or fully understand the low-level implementation of the high-level language statements they're choosing. This doesn't mean that we'll return to the days when major commercial applications were written entirely in assembly language. However, to reverse the trend of software running slower and slower even though CPUs are running faster and faster is going to require programmers to begin considering the low-level implications of the code that they write.

So, even if you never intend to write a single line of assembly language code again, learning assembly language, and learning to think in assembly language, is one of the best things you can do to learn how to write better assembly code.

[1] Moore's Law states that semiconductor technology doubles in capacity or performance at a given price point about every 18 months.

Randall Hyde is the author of the recently released "Write Great Code" and "The Art of Assembly Language" (both from No Starch Press), one of the most highly recommended resources on assembly.


Return to ONLamp.com.



Sponsored by: