Geeks With Blogs
Thomas May Curious Coding Complexities by Cogman

Why Assembly?

I was going to start the title as "The Art of Assembly" however, that title was already taken.

I am probably going to commit the biggest sin of modern developers, I am going to advocate that developers learn, and consider using, a bit of assembly!

I know, I can already hear the voices in my head saying "But Thomas, How could you advocate the use of such a low level, non-crossplatform, and painfully slow language?". Fear not voices, I haven't completely lost my mind yet. There actually are some really good reasons to learn such an archaic language. Let me illustrate that with my friend, the bullet point list (<ul><li></li></ul> To you HTML guys).

  • It is fun. No matter what you say, I say that the most enjoyable part of software development is a good challenge. Assembly provides such a challenge. It is strangely satisfying to write something that translates directly (in most cases) into a CPU instruction, to know exactly what is going on “under the hood”.

  • You control everything. Yes, you control everything when it comes to assembly. There is no ambiguity or guessing on what the compiler might do, it is all up to you. You think you could do things better using some non-standard calling convention? Go for it. You have the power. You want to use some new wiz-bang instruction on your new CPU? Go for it.

  • You can make it faster. Humans are really quite remarkable in their pattern recognization skills. Now, some may argue “A good compiler will do that for you!” An in many of the simple problems, that is quite true. However, if you introduce something complex involving, say, the SSE instruction set. Most compilers trip up and squander those beautiful instructions given to us by the CPU gods. Compilers, while being quite good, are not perfect. Humans can often come up with more optimal solutions then their automated counterparts.

  • It is smaller. This is almost a non-point in modern PC application development. However, embedded systems using 64k of RAM might be ideally placed for not bloated code generation.

Looking up any guys justification for why he likes to do assembly development and you might see a list similar to this. Now, don't get me wrong, I like tinkering with assembly. However, I'm not advocating that every application be completely written in it. There is a lot to say about the ease of using RAD Tools like WPF. However, if speed is the key, hand coded assembly is hard to beat.

Why not Assembly?

With that said, I can't in good conscience give a list of reasons to use assembly without giving one on why not to use it. Alas, the voices in my head make some pretty compelling points on why it is the devil (in most situations).

  • Developing in assembly is slow. When doing development in assembly you tend to miss some of the features of higher level languages such as named variables. Or even the easy declaration of a string within a function. Things like that. Assembly strips you of those things. It is straight movs, lea, pushes, and pops.

  • Assembly can look confusing. Line for line, assembly needs a lot more comments to explain exactly what is going on than a regular language might need. You get a lot of low level information thrown at you pretty quickly that you would normally just ignore in a HLL. Calling convention, for example, is a great example of things you probably never cared about.

  • Assembly isn't cross system friendly. This one isn't such a big issue because, seriously, how often do you expect your .NET application to run on a non-windows machine or even a non-x86 platform? Pretty much never. However, it is an issue for some. Perhaps you have a C application that targets both an ARM system and a PIC system. If you have any hand written assembly, it can quickly become a maintenance nightmare.

  • Bad assembly is slow assembly. There are many tricks to assembly that can seem almost counter intuitive. To know why and how they work requires some knowledge on what is going on underneath the instructions. If you just blindly write up some piece of assembly code, there is a good chance that the compiler will work better. Things as simple as the order of instruction execution can affect the speed of your application. Other examples include using instructions that have long been considered slower than a pair of instructions (enter).

This isn't exactly what I was planning on writing for this first little blurb, I was thinking of putting some actual assembly in here. However, after babbling on about the virtues of assembly I think I'll save that for the next post.

Posted on Wednesday, September 8, 2010 11:19 AM ASM | Back to top

Comments on this post: Awesome Assembly

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © CogBlog | Powered by: