Jeff Duntemann's Contrapositive Diary Rotating Header Image

Cleaning Up 21-Year-Old Writing

Context changes are expensive, whether you’re a writer or an operating system. That’s why I like long, uninterrupted days to write. Writing in small chunks on large projects never worked well for me; I’d rather pull three ten-hour days than find thirty disjointed hours in the course of a week and waste half of each of them trying to recover my train of thought.

So it’s been with the fourth edition of Assembly Language Step By Step. I’ve spent most of the last four days blasting away at it, and if I haven’t returned to the Carb Wars here, that’s the reason. All in good time.

This is a big project, probably the biggest I’ve attempted since Drive-by Wi-Fi Guide, and it’s likely to be eating my life until June. There’s a great deal of new material to be written, and a lot of concepts to be covered that just weren’t issues under DOS. For example, when you work at the assembly level under Linux, endianness comes into play and needs to be explained, even though 85% of the world’s desktop hardware is little-endian.

That’s actually been fun; as I’ve said many times, the very best way to make sure you understand something is to explain it to somebody else. What’s been humbling is running into writing bad enough to make me wince. Every so often, I have to push back in my chair, heave a deep sigh, and ask myself the purely rhetorical question: “Geez. Did I write that?” (I did. 21 years ago. Practice helps…)

No problem; this is what editors do, though I am very glad that we’re not using typewriters anymore. And unlike certain other projects I’ve worked on, the author in this case takes criticism well.


  1. Bob Fegert says:

    I have an early edition of this book…the writing is not bad at all.

    Will probably buy a copy of the new edition even though I rarely do asm any more on the PC. Mostly I write C and asm for microcontrollers now. When I write for the PC I just use Delphi…I’m a huge Delphi fan. 🙂

  2. Endianness is a funny thing. Even if software is only ever run on little endian, there are some classes of bugs that get shaken out by supporting big endian as well. The same is true for 32-bit and 64-bit. When I’m being a good boy, I test my software on i386 (32-bit, little endian), amd64 (64-bit, little endian), and sparc64 (64-bit, big endian). Also, though 85% of desktops are little endian, not all computers are desktops. For servers there is much worthwhile hardware that is big endian. So I feel dealing with endian issues is important.

    1. True, and worth mentioning in the book. Now, something I’ve been wondering: Is server software running on bi-endian hardware compiled as little endian or big endian? I know that Alpha, SPARC, and Itanium are bi-endian, but I’ve not seen any discussion of what endianness is actually used on bi-endian systems. I know it can go either way based on a recompile, but is there any consensus? And are there governing factors based on the “serverness” of the application?

Leave a Reply

Your email address will not be published. Required fields are marked *