A few months ago I received a well-used but not abused copy of Rakesh K. Agarwal’s book 80×86 Architecture and Programming (Volume II): Architecture Reference, published by Prentice Hall in 1991. This is an unusually well-informed book, no doubt because Agarwal was a member of the team that implemented the 80386 at Intel, and wrote some of the 80386’s microcode himself. The book is notable for being the second and only volume of a series (Volume I was apparently never published). Agarwal is also a co-author of an informative article titled The Intel 80386—Architecture and Implementation, published in the IEEE Micro magazine in December 1985.
80×86 Architecture & Programming Vol II
My copy 80×86 Architecture and Programming (Volume II): Architecture Reference came with handwritten notes sprinkled over various bits of the C-like pseudo-code that the book uses to explain the workings of the 386 microcode, as well as several explanatory notes in the instruction reference section.
Task switch microcode corrections
The notes were essentially corrections to the text, but pertained to very low-level details of the 386 implementation. For example where the book lists the registers stored during a task switch, a note mentions that the 386 in fact writes them to memory in reverse order. Who really cares about such a detail? Not a programmer using task switching, because for him or her a task switch is an atomic operation with more or less well defined inputs and outputs; whether register EAX gets stored before EBX or vice versa does not really matter.
BSR instruction clarifications
Since the previous owner’s name—Jeffrey S. Byrne—was written on the inside of the book’s cover, I punched it into a search engine. The answer to the question “who cares about such details” was immediately obvious. In the early 1990s, Mr. Byrne worked for the Cyrix Corporation and his name is listed on several patents.
Of course someone cloning an Intel 386 or 486 CPU would care about esoteric implementation minutiae. Cloning is a tricky business and it’s difficult to guess which details matter and which don’t.
Compatibility testing with existing software is useful, but it’s impossible to get 100% coverage, and it’s even more difficult to test software not yet released. A careful cloner will therefore replicate as much of the software-visible behavior as reasonably possible in order to be safe.
The book is an interesting and unexpected piece of computing history. It’s quite a useful book on its own, but the handwritten notes add a different kind of value.
