Many programmers still associate assembler with a difficult, low-level kind of programming. Most of them also think it is incomprehensible and impossible to master. In reality, things are not that bad and these perceptions are mostly founded in unfamiliarity. It is quite possible to learn how to write good assembly code without being a genius. On the other hand, don't think a few lessons in assembly will leave you producing faster code than the average Delphi/Pascal equivalent. The reason is that when you write Delphi code, you are competing with an efficient and experienced assembler programmer: the compiler. Overall, the code produced by it is efficient and fast enough for most applications.
Most people grab for assembler in order to achieve better performance for their software. However, the key to performance is mostly design, not choice of language. There is little point in trying to fix a bad algorithm through assembler. So, the first thing to do when you are experiencing bottlenecks, is to review your code architecture and Pascal implementation, rather than immediately taking recourse to assembler. Writing it in assembler is not going to turn a bad algorithm or a bad approach into a good one.
Similarly, most programmers erroneously believe that writing code in assembler by definition means it's fast and assume that code written in assembler is by definition faster than compiled Delphi/Pascal code. That is certainly not the case. Badly written assembler routines will perform on an inferior level and can even cause strange bugs and problems in your application.
There is however a good case for hand crafting assembler code in certain cases. Delphi's (Pascal) language is a general programming language and certain specialised tasks could be done better in assembler. Also, taking advantage of processor specific features might require manual code design.
It is not within the scope of this article to teach you the principles of assembler programming. There are other information resources out there discussing assembler programming. See Further Reading to find some pointers to relevant material.
Before resorting to rewriting code in assembler, investigate first where your bottlenecks are and why. A profiler might be a useful tool during this analysis. Once you have identified the cause, take a step back and look at the structure and algorithm. Often, you can get much better performance by revising the algorithm or the application design, rather than just throwing in some assembler. On the other hand, in some particular cases, assembler might indeed be a better and even simpler choice.
Once you conclude that assembler is actually needed, you should take time proper to draw up a plan for your code and design the algorithm. Only when you have a clear idea of what you want to do and how you will be implementing it, you can start coding. If you don't think about these issues, you'll end up with spaghetti code, convoluted statements and an unmaintainable program. Not to mention the possibility of introducing nasty bugs.
Next: Basic Principles
