Whyassembly

Why bother with Assembler?

The short answer for me would be: Quality & Performance. I want to create the highest quality software with top performance. Also, I want the least number of restrictions set upon me while creating software. I want total freedom during my creative process of crafting software from inspiration to a complete engineering solution.

When you look at a wood master craftsman and it’s tools, he/she is using the best tools available to create the highest quality furniture possible. A quality product shows in many ways that love & passion was poured into it during the creation process. Software is very similar in many ways. One needs excellent tools to create software. Great tools help in producing great products. The time invested in creating great software is valuable time. Creative processes can be disrupted to a great extend with half-baked tools or even worse buggy tools. You want to spend your time wisely.

Then, why not use a high level language instead of assembly? To me, this is a matter of how much control you want to give up at the cost of quality. The more control you give up to a compiler and run-time libraries, the less freedom you will have for the creation process. With assembly, you have absolute control over what you want to create.

With Microsoft Windows applications, it is even easier now because the Windows Operating system has thousands of ready made functions available for you to use. You don’t have to reinvent the wheel(s) anymore.

Visual MASM is my attempt to rectify the lack of a great IDE for MASM. I want the same power and ease of use for assembly like the Delphi IDE for the Delphi language or the Visual Studio IDE for the C#, C, and C++ languages.

I hope you will enjoy using Visual MASM to either learn assembly language programming or to create hobby or professional Windows applications.

Below are quotes from “The Art of Assembly Language”, by Randall Hyde

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.

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.

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.

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.

Assembly is hard to write

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 80x86 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.

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.

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.

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 language.

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 a HLL.

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 16 or 32 gigabytes 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.

Assembly language is not portable

This is an undeniable fact. An 80x86 assembly language program written for an IBM PC will not run on an Apple Macintosh. Indeed, assembly language programs written for the Apple Macintosh will not run on an Amiga, even though they share the same 680x0 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.

Final Word

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.