The Art Of Assembly


Call me crazy but I think learning Assembly language (ASM) is quite the beneficial accomplishment that any programmer should be happy to have under his belt. Not only are programs that are coded in Assembly smaller, they also tend to lead to faster code. Now there are a lot of misconceptions about the Assembly language  which are constantly in the forefront which keep programmers at by from the “evil” programming language known as Assembly (ASM) but HackTalk (with the help of the amazing book The Art of Assembly) are here to put them to rest.

What’s Wrong With Assembly?

Assembly language has a pretty bad reputation. The common impression about assembly language
programmers today is that they are all hackers or misguided individuals who need enlightenment. Here
are the reasons people give for not using assembly:

• Assembly is hard to learn.
• Assembly is hard to read and understand.
• Assembly is hard to debug.
• Assembly is hard to maintain.
• Assembly is hard to write.
• Assembly language programming is time consuming.
• Improved compiler technology has eliminated the need for assembly language.
• Today, machines are so fast that we no longer need to use assembly.
• If you need more speed, you should use a better algorithm rather than switch to assembly
language.
• Machines have so much memory today, saving space using assembly is not important.
• Assembly language is not portable.

source: The Art Of Assembly

It seems that programming in Assembly really is a waste of time and much more could be accomplished with Assembly but lo’ and behold, many of these reasons to avoid Assembly are merely misconceptions by the misinformed. Now to address each of these misconceptions and shed some light onto the otherwise hidden in the dark language of Assembly.

Assembly is hard to learn. So is any language you don’t already know. Try learning (really learning)
APL, Prolog, or Smalltalk sometime. Once you learn Pascal, learning another language like C, BASIC,
FORTRAN, Modula-2, or Ada is fairly easy because these languages are quite similar to Pascal. On the
other hand, learning a dissimilar language like Prolog is not so simple. Assembly language is also quite different
from Pascal. It will be a little harder to learn than one of the other Pascal-like languages. However,
learning assembly isn’t much more difficult than learning your first programming language.

I’d have to admit that if there is anything hard about Assembly programming it is simply that the syntax used is unlike any other languages that are the buzzwords of today and so many new programmers may be turned of to it because of it’s readability or lack thereof which bring us to our next point.

Assembly is hard to read and understand. It sure is, if you don’t know it. Most people who make
this statement simply don’t know assembly. Of course, it’s very easy to write impossible-to-read assembly
language programs. It’s also quite easy to write impossible-to-read C, Prolog, and APL programs. With
experience, you will find assembly as easy to read as other languages.

As with anything, unfamiliarity can cause confusion but we shouldn’t judge all of our opinions because of unfamiliarity.

Assembly is hard to debug. Same argument as above. If you don’t have much experience debugging
assembly language programs, it’s going to be hard to debug them. Remember what it was like finding
bugs in your first Pascal (or other HLL) programs? Anytime you learn a new programming language you’ll
have problems debugging programs in that language until you gain experience.

Debugging truly is a difficult process, even for the more advanced programmers. Debugging in Assembly is no different; as the complexity of a program grow so does the difficulty of debugging.

Assembly is hard to maintain. C programs are hard to maintain. Indeed, programs are hard to
maintain period. Inexperienced assembly language programmers tend to write hard to maintain programs.
Writing maintainable programs isn’t a talent. It’s a skill you develop through experience.

This is true, the level of expertise of the programmer factors into just how easy the project is to maintain, this is the same for C,Python,PERL, and yes, even Assembly, but it is not a reason to shun Assembly from the ranks.

Assembly language is hard. This statement actually has a ring of truth to it. For the longest time
assembly language programmers wrote their programs completely from scratch, often “re-inventing the
wheel.” HLL programmers, especially C, Ada, and Modula-2 programmers, have long enjoyed the benefits
of a standard library package which solves many common programming problems. Assembly language
programmers, on the other hand, have been known to rewrite an integer output routine every time they
need one. This book does not take that approach. Instead, it takes advantage of some work done at the
University of California, Riverside: the UCR Standard Library for 80×86 Assembly Language Programmers.
These subroutines simplify assembly language just as the C standard library aids C programmers. The
library source listings are available electronically via Internet and various other communication services as
well as on a companion diskette.

Of all of the misconceptions about Assembly that have been listed, this is the one that I am slightly experiencing now but I experienced it when learning PERL, I also experienced it when learning Ruby or any other language I have attempted.

Assembly language programming is time consuming. Software engineers estimate that developers spend only about thirty percent of their time coding a solution to a problem. Even if it took twice as much time to write a program in assembly versus some HLL, there would only be a fifteen percent difference in the total project completion time. In fact, good assembly language programmers do not need twice as much time to implement something in assembly language. It is true using a HLL will save some time; however, the savings is insufficient to counter the benefits of using assembly language.

Not much to say here except that numbers don’t lie.

Improved compiler technology has eliminated the need for assembly language. This isn’t
true and probably never will be true. Optimizing compilers are getting better every day. However, assembly
language programmers get better performance by writing their code differently than they would if they
were using some HLL. If assembly language programmers wrote their programs in C and then translated
them manually into assembly, a good C compiler would produce equivalent, or even better, code. Those
who make this claim about compiler technology are comparing their hand-compiled code against that
produced by a compiler. Compilers do a much better job of compiling than humans. Then again, you’ll
never catch an assembly language programmer writing “C code with MOV instructions.” After all, that’s
why you use C compilers.

This really is a load of bollocks as it’s almost like saying, “Pssh, there’s no need for math skills, computers and calculators never mess up at math and do it pretty fast so there is no point in learning how to even bother calculating by hand.” Sure the computer can do the math, but we, the human, programmed the computer. Any good mathmatician could solve an equation with as much grace and ease as a computer.

Today, machines are so fast that we no longer need to use assembly. It is amazing that people
will spend lots of money to buy a machine slightly faster than the one they own, but they won’t spend any
extra time writing their code in assembly so it runs faster on the same hardware. There are many raging
debates about the speed of machines versus the speed of the software, but one fact remains: users always
want more speed. On any given machine, the fastest possible programs will be written in assembly language2.

Assembly programmers get right to the point with their code because they know, and value, speed and space two things that work very well with our modern computers. What’s the point of having 4gb of RAM if just one program will take up 3 of those gb? It seems that as more RAM is added to a system programmers assume it is alright to simply use it all up in their single application.

If you need more speed, you should use a better algorithm rather than switch to assembly
language.
Why can’t you use this better algorithm in assembly language? What if you’re already using the
best algorithm you can find and it’s still too slow? This is a totally bogus argument against assembly language.
Any algorithm you can implement in a HLL you can implement in assembly. On the other hand,
there are many algorithms you can implement in assembly which you cannot implement in an HLL.

This is a good point that I’d like to bring up. I constantly hear, “forget assembly, just get a better ‘algo’ .” There truely are times when something will run slow regardless of it being programmed in Assembly or any other language.

Machines have so much memory today, saving space using assembly is not important. If
you give someone an inch, they’ll take a mile. Nowhere in programming does this saying have more application
than in program memory use. For the longest time, programmers were quite happy with 4 Kbytes.
Later, machines had 32 or even 64 Kilobytes. The programs filled up memory accordingly. Today, many
machines have 32 or 64 megabytes of memory installed and some applications use it all. There are lots of
technical reasons why programmers should strive to write shorter programs, though now is not the time to go into that. Let’s just say that space is important and programmers should strive to write programs as short as possible regardless of how much main memory they have in their machine.

Exactly what I was saying earlier about how programs are just beginning to take up way too much RAM now-a-days.

Assembly language is not portable. This is an undeniable fact. An 80×86 assembly language program
written for an IBM PC will not run on an Apple Macintosh4. Indeed, assembly language programs
written for the Apple Macintosh will not run on an Amiga, even though they share the same 680×0 microprocessor.
If you need to run your program on different machines, you’ll have to think long and hard
about using assembly language. Using C (or some other HLL) is no guarantee that your program will be
portable. C programs written for the IBM PC won’t compile and run on a Macintosh. And even if they did,
most Mac owners wouldn’t accept the result.
Portability is probably the biggest complaint people have against assembly language. They refuse to

use assembly because it is not portable, and then they turn around and write equally non-portable programs in C.

This is another complaint I frequently see and upon asking which languages the person codes in I get stuff back like, VB, VB.net, Visual C, all languages that are just not in any way portable which just causes me to chuckle to myself.

Yes, there are lots of lies, misconceptions, myths, and half-truths concerning assembly language.
Whatever you do, make sure you learn assembly language before forming your own opinions. Speaking out in ignorance may impress others who know less than you do, but it won’t impress those who know
the truth.

Couldn’t have said it better myself.

I Want To Learn!

If this article has opened your eyes to Assembly language programming then by all means check out The Art Of Assembly as a free ebook at http://bit.ly/au6Ee

Advertisements

3 Responses

  1. Very nice — one doesn’t see many assembly programmers out in the field today (except for certain scientific and purist communities).

    I’m all for learning about assembly code, if nothing else, for a conceptual understanding of how computers work. Many programmers forget (accidentally or intentionally) that code reduces to atomic machine instructions. This is a dangerous state of mind, because it can lead to much more careless coding, memory leaks, inefficiency, and even weak/incorrect code, especially relating to race conditions and deadlock. So, I think there is a very good case for at least learning how the machine operates at the assembly code level.

    However, I personally find it tedious to think at the step-by-step level required by assembly programming, as opposed to using a more conceptual programming model present in a higher-level language. Plus, modern compilers are built so that they generate correct assembly code for the input provided, which is a convenience. I prefer to think of my code this way (and I guess that most other computer scientists do as well), but I recognize that some may choose to think more atomically in their operations.

    “Yes, there are lots of lies, misconceptions, myths, and half-truths concerning assembly language. Whatever you do, make sure you learn assembly language before forming your own opinions. Speaking out in ignorance may impress others who know less than you do, but it won’t impress those who know the truth.”

    I agree with this quote too! Suffice it to say that any good computer scientist or developer must have a good familiarity with basic machine functionality, a big part of which is, of course, assembly language or machine code, if you are a masochist 😉

  2. Hi! I was surfing and found your blog post… nice! I love your blog. 🙂 Cheers! Sandra. R.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: