I typically run across gurus at SO and other places (instructors, book authors etc.) that would say something along the lines "This will cause alignment issues" or other low level tidbits.

I want to learn about all these tidbits that are relevant to programming. Now usually when I see low level books (computer architecture books for example) they are too low level and geared towards people whose primary area of interest is computer architecture and not software design.

Do you have recommendations for books that go through low-level stuff that is relevant to programmers?

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

4

You want "books that go through low-level stuff" but you do not want books that are too "low level"? Learning architecture for some programmers can be extremely advantageous. Analogous to a web developer understanding the TCP/IP stack. It is never all that useful until you REALLY need it. \
–
ChrisJun 23 '11 at 17:56

1

@Chris: What I meant was "low-level for programmers"... technically we can go as far as full blown CPU-architecture, and no doubt it will be useful one day, but considering we all have limited time, a book that teaches low-level stuff that all programmers should know about will be perfect.
–
SamaursaJun 23 '11 at 18:29

In that case any introductory book will get you in the right direction, where you take it after that is your choice based on need or desire.
–
ChrisJun 23 '11 at 21:11

Someone who drives a car with an automatic transmission benefits from knowing what one is, and how it works, while driving. I believe you become a better programmer by learning to program at least a little bit, in assembly language, the same way that I think you become a better driver when you learn to "drive stick".
–
Warren PJun 27 '11 at 13:35

8 Answers
8

A nice set of books for precisely this purpose is Randall Hyde's "Write Great Code" series
(Vol.1Vol. 2): description of machine architecture explicitly from the perspective of what you need to know to write efficient code in high-level languages.

Which high-level languages would this apply to? Would this include Python, JavaScript, C#, Scala for instance?
–
JobJun 23 '11 at 18:02

@Job - I haven't read the books, but I'd say it would apply to any that would/could take advantage of things like multi-threading and 64bit processing. Running the languages you mentioned would probably make that knowledge useful (especially if you're a server admin, too, or run those languages outside of a web environment).
–
ShaunaJun 23 '11 at 18:35

Hyde is an Assembly language guru, so to him "high-level" mostly means C. But his content is just as important for users of even higher languages; Strings, procedure calls etc. really aren't all that different on the hardware level, whether they are declared in C or in Python.
–
Kilian FothJun 24 '11 at 6:00

I would think any native compiled language (C,C++,Pascal,Objective-C) that also allows a bit of assembly language, would benefit most from this book. However, people who use Python, and write extensions for it in C, or even people who use java and don't use any native methods at all, could do with a little more thinking about the cost of what they're doing, and how to do their work efficiently within the platform they are using.
–
Warren PJun 27 '11 at 13:31

Although I have not read the books yet, I'll select this answer as correct based on the book's reviews/summary.
–
SamaursaJul 5 '11 at 17:28

Sadly I don't know a modern equivalent to Microprocessors: A Programmer's View by R. Dewar. The nearest I know of is Computer Organization and Design, Fourth Edition: The Hardware/Software Interface by David A. Patterson and John L. Hennessy, but I'm not sure that you won't consider it too low level; you'll for sure do it for their other opus, Computer Architecture, a quantitative approach.

I find "Computer Architecture: A Quantitative Approach" by Hennessy and Patterson (Amazon link) to be a very strong and solid approach to computer architecture, with quite a few case studies that are directly relevant to programming.

It's used to various extents in several undergraduate and graduate level CS architecture courses in the US.

Few students studying computer science or computer engineering will ever have the opportunity to build a computer system. On the other hand, most students will be required to use and program computers on a near daily basis. Computer Systems: A Programmer’s Perspective introduces the important and enduring concepts that underlie computer systems by showing how these ideas affect the correctness, performance, and utility of application programs. The text's hands-on approach (including a comprehensive set of labs) helps students understand the “under-the-hood” operation of a modern computer system and prepares them for future courses in systems topics such as compilers, computer architecture, operating systems, and networking.

It is a lot of work, but Programming Language Pragmatics might be exactly what you are looking for. The book is theoretically mostly about parsing and compilation (which is essential knowledge for those who want to really learn programming) and in the process you'll wind up learning how language concepts translate into what is going on at a low level. Better yet you'll learn this for many languages at once and you'll be able to intelligently compare and contrast how different languages actually work.

I can't recommend it unless you can dedicate several months to actually learning the material. It isn't the sort of stuff that you just skim and are suddenly enlightened. But if you're serious then I highly recommend it.

It might be false in biology, but in computer-science, "ontogeny recapitulates phylogeny" pretty nearly. A historical overview of computer architectures since the first computers is a great way to understand the subject of computer architecture from a programmer's perspective; computer designs are almost all refinements of earlier designs.

That is, I recommend studying complete working older system designs, insted of theoretical "computer architecture" books they give you in computer science. To really understand systems design, and to do a really great job at writing software. Intuitive grasp of architecture of computer systems requires mastery of many concepts. I think if you start back when computer architectures were more manageable in size and scope, you might get father along in your goal to write better code.

(That "write great code" book series that another guy mentioned looks great, by the way, and I've edited my question to remove any aspersion that I had previously cast on learning-from-a-book, because it looks great!)

Some things that teach computer architecture really well:

I like to pick machines from the 1980s as starting places for explaining and demonstrating things to people, because that's when I started using computers. I have used the commodore 64 programmer's reference guide, to show people a jumping off place where knowledge of programming, and knowledge of computer architecture meet each other.
With such a book, and perhaps a commodore 64 emulator running on your PC so you can try stuff, you'll learn about how computer systems in the classic 1980s incarnation of computer architecture, are really built. In my view, one concrete example is a better place to start, than a dozen theoretical models that are missing the real world details that make things work. If you know what a register is, what an ALU is, what a bus is, and what a clock is, and what signalling systems are used in an old 1980s design, that will give you the fundamentals that you need to know to understand something recent, like Intel's "sandy bridge architecture". Historically, look back at the originals, for example look up "Von neumann" architecture, on wikipedia.

Moving forward from my first point a few years; Learn about the original IBM PC architecture, 8086 assembly language, and the ISA bus. From this, and its limitations, understanding of what an "Intel COre i7" CPU contains, and what the PCI and PCI-e buses do and why you need them, can proceed more naturally. PC architecture today still has a bit of "hangover" from the original IBM PC design. The way initial program (operating system) loading (boot-up) happens on a 2011 PC still owes a lot to the heritage of the original IBM PC and its ROM BIOS, and its CMOS settings in an original PC.

Use and modify a pre-configured build of Linux that works on some embedded non-PC device, and you'll learn a lot about embedded computer architecture, not only the technical architecture, but why some of the features are there. A nice example that is available cheap is the TS-7200, which has a nice PC-104 (ISA Bus, as in the original PC). PC-104 (embedded 16 bit ISA-bus that is pin compatible with the IBM PC/AT 80286 era PCs) computers are a great way for a non-board-designer to build an embedded system, because the modules are stackable. Want some extra IO or peripherals? Just stack up a few modules. The TS-7200 has a non-x86 core (an ARM9 cpu) that is capable of running either big-endian or little-endian. If you haven't run into "endianness" in your architecture learning journey yet, that's a good place to encounter it.

Most books on assembly language will discuss relevant architecture features, but usually only for the architecture the book is targeting. So you'll get information on cache spills and MMU page-mapping techniques, but probably not anything on endianness.