DevCity.NET - http://devcity.net
Write Great Code – Volume 2: Thinking low-level, writing high-level by Randall Hyde
http://devcity.net/Articles/271/1/article.aspx
Fadzai Chamba
Fadz has been coding since 1993 when he was 13 years old when he first saw a computer that worked at St. Ignatius College in Harare Zimbabwe. His first programming experience was in GWBASIC. He thought he was learning the basics of computers and before long he was the renouned 'computer expert'. He later learned to use COBOL, Pascal, C, C++, PROLOG, Visual Basic, Java and Visual C++. Because of his first experiences he chose to ply his trade in Visual Basic. He came across .NET in July/August of 2003 and has been using it since. He has worked with VB(6) since October 2000, first as a Free lance developer, then for a company back to free lance. This yo-yo experience has continued to this day when he is now a Free Lance developer and starting a business in the Multi media field. He is a vbCity Guru who goes by the alias 'fabulous' and Spends a lot of his time inside .NET and the VB.NET and C# compilers. Fadz is also a DevCity .NETFella Award winner and constantly studies to improve his skills in .NET. 
by Fadzai Chamba
Published on 9/24/2006
 

Every programmer concerned with application performance of the code they write needs to have a good profiler at hand. This must be used to profile your applications regularly to know what part of your code is negatively affecting performance. A paradox in programming is that often, poor performance is caused by bad application design and not bad code, but you cannot verify the application design until you have written some code. However, some good designs are hampered by bad code and a profiler can only point out the bottlenecks, it cannot change your code and/or design.

Bad code must be dealt with before a single line of code is written (so to speak).   This is achieved by acquiring some good coding habits and arming yourself with knowledge of the internal workings of a CPU, how your particular compiler works and how your high level code is optimized and translated to low-level machine code. This is where this book, and series thereof, comes in.

No Starch Press presents a great book that answers a lot of the fundamental questions of life, like "what is an array?" and "where do strings come from?"


 


Introduction

Introduction

This book, the second in a series, is based on the premise that, "in order to write the best high level code, one needs to learn assembly language." The good thing about it is that you don't have to lay the book down and enroll in an assembly language course before reading; the book will teach it to you.

Before I proceed, I must mention that although this is a site dedicated to .NET, this book is not about .NET. You will not find comparisons between datasets and data readers or C# and Visual Basic.NET. This is a rare gem that is relevant to all languages. In it you will find code samples in C/C++, Pascal (Delphi), Basic (Visual Basic) and different dialects of assembly language, including the author’s own High Level Assembler (HLA).

The prospect of learning assembly language might seem daunting, particularly to those who once tried and failed, or those without formal IT education. If that is you, you'll be pleased to know that contained in these pages is a two chapter crash course on assembly languages for the 80x86 and PowerPC CPU architectures. While this isn’t enough for you to start coding in assembly, you will be able to read assembly code with some idea of what's going on.

What you will learn

At one point I had to put the book down and get a notepad (the paper version) in order to take some notes because, particularly in the first quarter of the book, I was learning something new about the low-level details of memory addressing and CPU architectures on every page.

Randall Hyde challenges a lot of assumptions that developers may have about their code and leads you much further than you may have gone in the past.  For instance, when I did my CS course, a variable was defined in one sentence. Later as a teacher, I defined it in a paragraph and a couple of examples.

Hyde devotes 49 pages to telling readers what a variable really is, how it works and where it is stored.  Quality stuff, I tell you.  As if that isn't enough, there are 37 quality pages on arrays, 32 pages on strings and hope for those who gave up on C++ because pointers are effectively demystified.

You will learn the concepts of compiler operation and how to analyze compiler output. How debuggers work and how to step through your code looking not at the source code, but at the assembly generated for it through the disassembly window as I have been doing for a while now. This allows you to really compare what assembly code is generated for your high level statements and make intelligent and informed decisions on which statements you use.

 

Chapters of interest

The chapters on 80x86 and PowerPC assembly for high level language programmers are of great interest. These chapters contain invaluable information on CPU registers, and memory addressing modes that give you a greater understanding of how your code is working.

The chapters on variables, strings, arrays and pointers are very informative. You also get the low down on control structures and programmatic decisions. And there is a great chapter on  functions and procedures which covers their calling conventions and the overheads associated with them.


 

Summary

Who should read this book?

I know I should read it again.

Anyone who found the book title interesting probably needs this book.    .NET programmers who have often found themselves analyzing the IL generated for different statements in their .NET language of choice will find this very useful (I did). Anyone who has opened the disassembly window and tried to make sense of its contents when debugging will get help from the two chapters on assembly, let alone the rest of the book. And finally, anyone concerned with writing better code needs this.

Verdict

Guilty as charged. (I do get carried away sometimes don't I?) Set aside some money and buy this book, or get a friend to buy it and get it from them while still in the store. When you get home, read it TWICE so that you master what is in these pages. Then read it again.

It helps you understand what your code is doing, and with this in mind, enables you to make better decisions about the code you write and the high level statements you choose. Hence, you will be able to write smaller, more memory-efficient, CPU-efficient, whatever is a priority to you efficient code, because you will understand how to make it so.

Conclusion

This is a great book that I would recommend for professional developers who need to serve their users with the best possible code. Hyde does not take the stance of an expert in your language and the types of programs you write.   Instead, he tackles the very fundamental concepts of programming that are often overlooked, ignored, and in some cases simply misunderstood. He allows you to use your understanding of the compiler you use, together with your experience to determine which high level statements you use.

He describes common optimization options in detail to help you understand what your compiler does to your code when these (optimizations) are enabled. With the knowledge gained from this book you can write great code that will not hamper the compiler’s efforts.