Customer Reviews

Write Great Code: Volume 1: Understanding the Machine

5 star:		(16)
4 star:		(2)
3 star:		(1)
2 star:		(0)
1 star:		(0)

 

 

As new computer languages arise that have more power, like Java and C#, have you noticed something? Often, someone might learn programming without ever having to know about the architecture of a von Neumann machine. Yet most computers since World War 2 have this design at their very core.

Hyde fills in this gap in the education. At one level, you should read it for "culture". It explains the basis of programming. Granted, for most of us, there is often no direct need for understanding how binary arithmetic is implemented. Or why registers can speed up performance. And what is cache memory, really? We finesse our ignorance by invoking libraries that subsume these details.

The material that Hyde explains may occasionally be of use. What if you need to write some of these low level procedures in assembler, to reduce a bottleneck? After using a profiler on your runtime code to find the key routines, do you have any idea how to improve matters?

Even out of pure intellectual curiosity, you should know what happens at the silicon. Or are you just a wage slave? Programming because you have to? A good programmer who loves to program should know this material. Also, out of pure self interest, you should always burnish your programming skills. To separate you from your peers.

This is a great book but I have to disagree with the overall viewpoint. I've been doing embedded programming for a while and if that's all I'd ever done I would totally agree that understanding low level concepts helps write better code. However, I also write a lot of code in C#. People who normally use high level languages such as C#, VB.Net, or JAVA are probably not going to benefit much from this book. These languages are so far abstracted from the hardware level that the concepts are hard to apply anywhere. On the other hand, if you still use malloc on a daily basis, you need to read the book :) Anyway, the book is easy to read and I never caught any errors. If you want to learn about computers at a low level, then this is a great book to start with!

As computers have gotten smaller and faster, developers have become more and more removed from the lowest levels of programming. Randall Hyde's new book Write Great Code - Volume 1: Understanding The Machine (No Starch Press) will help you get back to the basic levels of how computers work and how that affects your programming.

Chapter List: What You Need To Know To Write Great Code; Numeric Representation; Binary Arithmetic And Bit Operation; Floating-Point Representation; Character Representation; Memory Organization And Access; Composite Data Types And Memory Objects; Boolean Logic And Digital Design; CPU Architecture; Instruction Set Architecture; Memory Architecture And Organization; Input And Output (I/O); Thinking Low-Level, Writing High-Level; ASCII Character Set; Index

It used to be you couldn't program at all without knowing this material. The design of a program was tied closely to the machine architecture, and it drove the instruction set and the overall programming decisions. But now the higher-level programs have made it easier for mere mortals to write a program and be completely oblivious to how a CPU executes an instruction or loads data from memory. Hyde goes into great detail on all the instructional design and theory, and I'd venture to guess that a very small number of programmers (and I'm not one of them) know most of this information. The assumption is that you'll know at least one procedural language (like C, C++, BASIC, or assembly). He rotates examples among C, C++, Pascal, BASIC, and assembly so as to keep the examples as language-neutral as possible. The goal when you finish the reading is that you should understand exactly how the architecture of a CPU affects your program, and how to make programming decisions that will lead to efficient programs. This volume will be followed up by another book titled Think Low-Level, Write High-Level. For me, I think this is where a lot of this information will come together.

Foundational information presented in great detail, and a book that all serious developers should take the time to read and understand.

A great programmer has both a compiler and a CPU in his head. You have to understand how a machine operates to understand how you can get yourself out of trouble if you have a problem that you don't understand. Particularly when you are using a systems language like C, C++ or assembler.

This book provides an in-depth understanding of the working of a CPU. And it does it in a well written and organized way with very effective use of illustrations. This is not the assembler book you remember. This book is targeted at systems level programmers who need to understand the machine in order to make the best use of it.

Given that many programmers start by learning Java, and learn C as their low level language, I can see there being a good market for this book. If you are working on a large C or C++ application, or are writing C libraries for Java, and you don't understand the basics (memory management, stacks, bit shifting, assembler opcodes, etc.) you should get this book.

I can't wait for the final 3 volumes of the series (hope they come out soon).

Hyde is too conservative in his advisement: though the book contains snippets of assembly and C/C++ code (and oddly some Pascal and Delphi), you can still read this book by skipping over the code (the book wouldn't be much harder to understand than if you did know one of these languages).

The only criticism I have of the book is the ordering. Basic memory and CPU chapters should go up front because the first 4 chapters about integer, float, and character representation in memory are too dull coming one after the other the way they do. Besides, most of the chapters of this book can be read independently of the others (a nice feature), so they could be rearranged in any order. Hyde at least needs to include a note mentioning this up front.

This book should be read early in the learning of programming. The only caveat is that Hyde overstates the benefits of the optimizations he describes; that is, rather, he gives the wrong impression to programming initiates: worrying about such optimizations are just not worth it these days unless you are writing a system level process (like a driver), writing a portion of code that will execute repeatedly, or writing for a non-PC device.

But whether you incorporate such optimizations into your code, knowing what the machine and compiler do is always to your advantage; one day, it may save your code.

This book argues that in order to write efficient (high level) code, you must first understand how the low-level system operates. If you have a better understanding of how your computer performs mathematical computations, it might change how you write code for certain algorithms. In any case, this book is one of the most comprehensive volumes in computer architecture that I have seen.

Proceeding from most simple to most complex, the book begins by discussing how numbers are stored, and eventually moves (in the final chapter) to how I/O works. I found the initial chapters most interesting, which included information on binary and hexadecimal numbers, how characters are stored in memory, how the computer handles various floating-point precisions, and how you would go about designing your own character types. It's all basic computer science stuff, but fun to read either as a refresher or for the first time (in case you skipped that day of class).

Each chapter takes on a more complex aspect of the computer, moving from memory representations to CPU architecture. Naturally a discussion about the CPU leads to information on CPU instruction sets. Finally, the author wraps up the book with a discussion on I/O, which includes not just disk access, but the keyboard, USB, optical drives, and the file allocation table.

My only complaint with this book is that I wish that with the impending move to 64-bit architecture, there was more information included in this regard. However, in spite of that small omission, this is a really fascinating book to read. As you write your next bit of code, if you think about what the computer is really doing under the covers, then I think this book has achieved its goal.

I still have to read last couple of chapters but I'm ready to post a review for this book.

The book gives pretty informative review of the hardware worth to take into account when writing code.

For someone having generic understanding of the hardware pieces (especially internal parts of CPU) this book gives very good overview of those parts and their interactions, as well as possible implications organising code and variables.

I think chapters telling about phisical implementation of CPU, description of logical units dealing with decoding instructions, choise of instruction set - are very intersting and useful for understaing how machine works and how code and data organization can help CPU perform better.
The same can be said about information covering memory units (main RAM, L1, L2 level caches, and overall memory hierarchy), instruction prefetching, data/code caching.

The book doesn't drill down to the deepest levels of detail on all topics (and I think it's not the purpose of this book) but information is enough to create pretty informative picture in mind; and for the omitted deep-level discussions author refers to several other books.

As the title states there is a machine underneath the high level code most developer's use today. As we code in today's hectic environment of changing requirements and tight deadlines, we often lose site of this. In a world where programmers work for many employers, on many platforms, using many different compilers it is beneficial to always remember how the code we write will translate to something the computer can use. Many programmers today haven't had any exposure to assembly language or writing their own compilers. This book is a great primer, or reminder, of how computers and its instruction set work. This is definitely a book to have in your library, knocking the dust off frequently for review.

This book will probably be accessible to most readers and will be very useful to those who have had little exposure to computer organisation. In other words, it should be considered a primer and is probably less interesting to people who have read books on this topic before --such as for example Tanenbaum's book.

I *have* read Tanenbaum's book, and as a result I consider the purchase of 'Write Great Code - Volume I' a waste of my money. However, this book is not to blame for my reading background; since it delivers what it promises and both the writing and the content are good, I decided to rate 'Understanding the Machine' with 5 stars.

This is a most interesting book. It's positioned kind of halfway between the book on a programming language and the data book for the CPU. It contains a lot of information that the computer science classes don't bother to include. On the whole it is rather machine independent (hard to do in today's world where the Pentium class machines are so prevalent), so if you are working on a Power PC or an ARM chip the material here would still have value.

Having said that, the majority of people in the computer business today would waste their time reading this book. Today's "computer professional" works in Excel or Access, perhaps doing just a bit of programming to create a macro, or a little VBA to do something special. That a Hex 41 represents an A is of no value to them. Indeed most wouldn't even know what Hex means.

Those who want to go a deeper however, will find this book to be a great help. There are still a lot of programmers out there who are doing some kind of hardware driver to make a peripheral work with a system. Or they may be doing an embedded system of some kind, and here's the way to get started.

There is one minor complaint. In the definition of great code, it seems clear that Mr. Hyde like tight fast running code. With today's processors running at gigahertz speeds with scads of memory, an argument can be made that the size of the code or the number of cycles it takes is almost insignificant. But if your job is to run something in real time....