Slashdot Mirror


Assembly Language for Intel-Based Computers, 4th edition

Alexander Moskalyuk writes "Most of the people I know have a love-hate relationship with Kip Irvine's Assembly Language for Intel-based Computers. Ask any student who used this textbook and you will either get a cheerful 'I've used it, it's great, I learned Assembly, and it has lots of useful examples' or resentful 'The book is horrible, hard to follow and full of code that is irrelevant to the contents of a specific chapter.'" Alexander's review of the book (below) concentrates on its role as an instructional aid, and on the differences between the third and fourth editions. Assembly Language for Intel-Based Computers, 4th edition author Kip R. Irvine pages 676 publisher Prentice Hall rating 8/10 reviewer Alexander Moskalyuk ISBN 0130910139 summary Authoritative source on Intel assembly programming and Assembly language fundamentals

Popularity Contest of One A quick search on Amazon, however, reveals that for the keyword 'Assembly' Irvine's book is still the bestseller. The fourth edition of the text tops the list and the same was the case with the third edition. The university where I teach uses Irvine's textbook for its introductory Assembly courses. We've used third edition throughout last year, and decided to stick to the third edition (with fourth recommended) during this academic year as well, just to avoid having students cash out for a newer version of the same text. Since this is a Prentice Hall textbook targeted mostly towards Computer Science and Engineering programs, welcome to the world of academic pricing -- the list price of fourth edition is $76.

Third vs. Fourth

The first natural thing to do is to see whether the fourth edition of the text is superior to 1999's third edition. Just looking at the table of contents, you can see that a lot of new material has been added, even in the introductory chapters. Furthermore, fourth edition has a new version of the first Assembly program introduced to the reader. Instead of the notorious 'Hello, World' example, it's now adding three numbers. Hello, World would usually be the thing to introduce first in classes with C++ or Perl being primary languages. However, in Intel Assembly the example just confused students more, since printing the phrase "Hello, World" to the screen involved dealing with interrupts, and that topic would not be covered until later in the course.

Irvine also got rid of his "Using the Assembler" chapter, which might be a nuisance for some of the readers and relief for others. The book comes with Microsoft ASM and thus all examples assume using MASM for their compilation needs. In my class, however, NASM has always been the compiler of choice, partly because it's easier to introduce to novice programmers who have not been exposed to Assembly before, and partly because of the tradition -- NASM was the compiler that previous instructors used, and thus was available on university servers and familiar to tutors in the labs. Vaguely named "Advanced Topics" chapters are almost gone and now changed into much more informative "16-bit MS-DOS programming," "Expert MS-DOS programming," "BIOS level programming," "32-bit Windows programming" and "High-level language interface." The last chapter of the book is now the only one bearing the name "Advanced Topics" and discusses things like "Hardware control with I/O ports," "Intel instruction encoding" and "Floating-Point arithmetic."

Some appendices are gone as well. The third edition included such topics as "Binary and Hexadecimal tutorial" (now moved to be a part of the introductory chapters), "Using debug" (tutorial on using debug.exe on Microsoft platforms to trace the Assembly code -- it's a shame the appendix is pulled out of the book, since now either students have to learn the commands for debug.exe themselves or additional class time needs to be spent on that), "Microsoft CodeView" and "Borland TurboDebugger" (both gone for good) as well as "Guide to the sample programs" (in this new edition, that successfully migrated into "Installing and using the assembler").

Except for the shocking absence of debug.exe tutorial appendices, the fourth edition looks much more straightforward and useful. Speaking of appendices, there are four of them now - "Installing and using the assembler," which few people ever bother to read when in class, "Intel instruction set," which is the mother of all useful appendices (in fact, I've seen good students get by on nothing else but this appendix), "BIOS and MS-DOS interrupts" and "MASM reference." The CD by the way, includes MASM, source code and macros for the book, as well as evaluation version of TextPad.

Academic value

Kip Irvine is usually accused of bringing up examples that confuse novice readers and trying to show off with his knowledge of IA-32 Assembly. Read the Amazon reviews to find out more. Personally I have never had problems with his style of writing. There were, though, some mistakes in the third edition of the book that would make an instructor pull his hair to pieces. Typos, grammatical errors and words that did not get picked up by the spellchecker were acceptable, but when the sequence of operations during code execution was described incorrectly, you can hardly be accused of being too picky, since you get students relying on the book for knowledge and being mad at you for flagging their code wrong on the test.

If you have the third edition handy, pages 234 and 235 describe the RCL and RCR operations, providing the incorrect order of operations and thus forcing students who use this textbook to learn these instructions to arrive at incorrect results when given a snippet of code to trace. Page 232 in the fourth edition now has the correct sequence of operations.

I would lie to you if I told you that I've read the whole book. Very few people would actually need to go through seven hundred pages, and some of the things discussed might never be useful even if you spent the rest of your life programming Intel Assembly 40 hours a week. But from the information that I got after reading the chapters that interested me (mostly introductory material and all chapters that cover instruction set and interrupts), the text seemed to present material in a clear and straightforward manner, with abundant examples.

A nice addition to Chapter 1 was an explanation of how virtual machines work, since the university uses Java as its core programming language. The second chapter goes on smoothly with careful introduction into the architecture principles and then switches into overdrive, presenting students with information on "Multi-stage pipelining" followed by reasonably simple material on "How programs run."

The book jumps into IA-32 architecture, although I wish that for introductory class the text would stick to 8086 architecture, and then have the 32-bit registers introduced. But generally it's a thorough and informative text for anyone deciding to learn programming Assembly language on Intel platforms, or just beginning Computer Science majors deciding to find out how the stuff really works as opposed to playing with high-level APIs.

The table of contents can be found at publisher's Web site. There's also a Web page for the book, where the author has posted some chapters in PDF format. The chapters published for free include Chapter 1 - Basic Concepts, Chapter 2 - IA-32 Processor Architecture, Chapter 6 - Conditional Processing, Chapter 11 - 32-bit Windows Programming, Chapter 15 - BIOS-level programming as well as Preface and Table of contents.

You can purchase Assembly Language for Intel-Based Computers, 4th edition from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

17 of 245 comments (clear)

  1. Re:Assembler is hard to follow? by Amazing+Quantum+Man · · Score: 4, Insightful

    Nah, it's just x86 assembly (and probably most RISCs, too...). X86 assembly is baroque.

    Try looking at the 68K instruction set, or the Z8000 (or Z80000) instruction set. Nice orthogonal instruction sets, no special purpose registers (except for the stack pointer - A7 and R15/RR14 respectively). Much more readable than x86 instructions.

    Disclaimer: I learned x86 long before I learned 68K or Z8K.

    --
    Fascism starts when the efficiency of the government becomes more important than the rights of the people.
  2. Ahh...memories by NPE · · Score: 4, Insightful

    I used this book (3rd ed I think) two years ago in my Organization and Architecture class, and I liked it. The book was an easy, quick read, which is a major deciding factor when you have 3 reading assignments a day. The author uses examples that actually show in code the concepts he's writing about, and the examples are short, to the point, and easy to understand. Assembly language is a rough language when you first pick it up, but I think this book helped me along rather nicely.

    --
    ~NullPointerException
  3. Yet another assembly book outdated at release by ehiris · · Score: 4, Informative

    I don't see any mention of IA-64 or Unix/Linux ...

    If you are looking for a assembly book that is fun to read and goes into Linux details try: "Assembly Language Step by Step"

    1. Re:Yet another assembly book outdated at release by WndrBr3d · · Score: 3, Informative

      I've read this book as well as the 'Assembly Language for Intel Based Computers', and honestly, the book "Assembly Language Step by Step" has to be one of the worst written books on programming in GENERAL I've ever seen.

      The initial topics jump all around from memory managment to how the BIOS works. It's insane. They'll seriously spend three chapters on actual memory addressing, but only use one to explain interupts.

      I think it's a book Linux users just want to have, so they feel that they wern't left out. Again, "Assembly Language Step by Step" is an awful book and should be avoided at ALL costs (unless you enjoy an enigma).

  4. A lost art, alas by Reality+Master+101 · · Score: 5, Insightful

    Z80 assembly language was the second language I learned (after BASIC, of course). I'm convinced that learning assembly language was key to making me the (humbly) great programmer I am today.

    I've ranted about this before, but I have to say it again: Programming is taught ass-backwards in college. Assembly language should be the FIRST thing taught, and then gradually building up to higher and higher levels of abstraction. All algorithm theory should be taught in assembly. When you've implemented algorithms in assembly, then there's no question that you know them far better than when they're surrounded by 7 layers of syntactical fluff.

    Look at the way EE's are taught: You start with the basics of transisters, resisters, capicitors, etc and work your way up. If EEs were taught the same way as programmers, they would start with plugging cards into PCs with component theory being taught as an afterthought!

    In my experience, I've often found that EEs converted into programmers are better programmers than people with CS degrees, and I think this is the reason. EEs are taught how to think early on at the component level.

    I should also say that it's a total myth that assembly language is "hard". It's not. It's simply "more". More detail, more instructions, more attention to what you're doing. Assembly itself is extremely simple. Get an instruction; execute it; move to next.

    Bottom line: TWO years of assembly before a student even sniffs high-level languages.

    I keep ranting about this, but I doubt that CS programs are going to change. I can always dream, though.

    --
    Sometimes it's best to just let stupid people be stupid.
    1. Re:A lost art, alas by Your_Mom · · Score: 3, Interesting

      Amen! I am glad (and relieved) that someone other then myself feels that way. I learned x86 assembly about a year ago during my junior year, its fantastic, I really got a grasp on what goes inside the processor, which, sadly, a lot of CS/CE students don't have. I think that it allows me to write faster code in my C programs by keeping in mind how it translated down to ASM.

      Its aslo handy to know for embedded systems.

      Also, I used Kip's book and I fall into the 'cool book' catagory

      --
      Objects in the blog are closer then they ap
    2. Re:A lost art, alas by Hard_Code · · Score: 3, Insightful

      "All algorithm theory should be taught in assembly."

      I'd argue that if your goal is to understand the concepts of an algorithm, using the dirtiest, lowest-level approach is the wrong way. You don't see the forest for the trees. Once you learn the concepts, you can apply them anywhere. That's not to say assembly isn't valuable. In fact, I think it is necessary for really understanding computers and programming well. But I think it is a hindrance when trying to learn higher level concepts. Assembly goes nicely with a CPU or compiler design course, but otherwise I think it is the wrong place to start to teach higher concepts. After all, high school physics doesn't start with the lowest level details of quantum mechanics and quarks and exotic matter. No, it starts with the "naive" and simple classic Newtonian mechanics.

      --

      It's 10 PM. Do you know if you're un-American?
    3. Re:A lost art, alas by sydb · · Score: 3, Interesting

      hmmm, I don't know.

      I agree that good programmers and engineers should understand assembly, if only because that means really understanding how a computer works.

      However, I don't think it has to be the first thing they learn

      Look at the way EE's are taught: You start with the basics of transisters, resisters, capicitors, etc and work your way up. If EEs were taught the same way as programmers, they would start with plugging cards into PCs with component theory being taught as an afterthought!

      But no! Plugging cards into PCs isn't electronics, it's technician work. I think you know this anyway, but your analogy is wrong. If EEs were taught the same way as programmers, they would learn about amplifiers, oscillators, tuned circuits, logic gates, flip flops, etc.

      Teaching assembly to programmers is more like teaching physics to electronic engineers. Most of them won't need to know it.

      In fact the thing that destroyed my career in digital electronics was being forced to attend classes on the mathematics of three phase circuits. There are some things people should not have to experience.

      But I agree, someone who claims to understand computers without at least being aware of the types of processes which go on at microprocessor level is a liar, and any self-respecting programmer or engineer should make it their business to have some knowledge.

      --
      Yours Sincerely, Michael.
    4. Re:A lost art, alas by Anonymous+Canard · · Score: 3, Interesting
      I've ranted about this before, but I have to say it again: Programming is taught ass-backwards in college. Assembly language should be the FIRST thing taught, and then gradually building up to higher and higher levels of abstraction. All algorithm theory should be taught in assembly. When you've implemented algorithms in assembly, then there's no question that you know them far better than when they're surrounded by 7 layers of syntactical fluff.

      I remember my first job out of college I wrote a little preemptive multitasking kernel in 286 assembly for MSDOS that I used to write a multithreaded spacecraft simulator with one thread dedicated each to I/O, electrical subsystem, state vector propagator, and telemetry. While assembly was a rite of passage for those of us who studied computers in the 70's and 80's, you no more need to learn assembly now than you have to learn set theory and understand the axioms underlying mathematics in order to understand how addition works.

      People learn quickly if the things that they are learning are useful to them, and at the level of abstraction that people need to use a computer these days I would rather point them toward Java, Visual Basic, or even HTML as a first programming language (of course since HTML is declarative you would want to use a corresponding DHTML language such as PHP, JSP, or ASP to round out the imperative elements of the course.) But starting with assembly would just bore students to tears; they would drop out simply because they weren't learning anything of any relevance to their actual use of computers.

      Assembly, like compiler construction and operating systems design, should be reserved for those who get some utility from the knowlege, or are planning on extending the field.

      --

      --
      BitTorrent in C -- LibBT
      http://www.sf.net/projects/libbt
    5. Re:A lost art, alas by jandrese · · Score: 5, Interesting
      Opinon on this is going to vary wildly, but I've seen two major schools of thought on this topic:
      • Computer Scientist standpoint: This says that you should never need to know about the hardware. You should be programming in sufficently high level languages like Lisp that keep you from knowing anything about the underlying architecture. Knowing about the architecture leads you to programming FOR that architecture, which is the first step towards unportable code. Also, most pure computer scientists are more interested in proving that their solution is correct that actaully solving the problem. These people often give lip service to the importance of knowing the architecture while simultaniously designing languages that no computer will ever be able to run and that nobody would ever ever want to program in (anybody have a spare Turing machine handy? Mine ran out of infinate paper tape.)
      • C Programmers point of view: This places the high level language as more of a glue between the programmer and the machine. You try to do things in ways that are optimal for the machine so your programs run fast, while still trying to be at least somewhat portable. (and hey, if you get it wrong, there's always #IFDEF right?). Most professional programmers seem to fall in this category, as it involves getting much more work done with fewer inductive proofs.
      I know I'm going to be flamed about the Lisp crack, but you have to admit, Lisp programs are portable.
      --

      I read the internet for the articles.
  5. Re:Assembler is hard to follow? by Tackhead · · Score: 3, Funny
    > Nah, it's just x86 assembly (and probably most RISCs, too...). X86 assembly is baroque.

    Calling X86 assembly "baroque" is like calling the Grand Canyon a "ditch".

    > Disclaimer: I learned x86 long before I learned 68K or Z8K.

    Disclaimer: I'm an old 6502 and 6809 dog.

  6. ARM by yerricde · · Score: 3, Interesting

    Try looking at the 68K instruction set, or the Z8000 (or Z80000) instruction set. Nice orthogonal instruction sets, no special purpose registers (except for the stack pointer - A7 and R15/RR14 respectively).

    Even better, look at the ARM instruction set. Every instruction can be conditionally executed based on the same flags that other archs (6502, 68000, ppc, x86, etc) use for branches. Heck, even the program counter is a general purpose register. If you want to learn on a simple ARM machine, start here.

    --
    Will I retire or break 10K?
    1. Re:ARM by jejones · · Score: 3, Informative

      Well, yeah, but...the conditional execution bits eat four bits out of every 32-bit instruction, which makes the constraints on immediate operands and offsets for base + offset addressing even more galling than usual on fixed-width instruction sets, for a payoff of uncertain value unless all you do is run the clever GCD code people always give as an example of how great ARM conditional execution is. Among the most perverse aspects are offsets whose ranges vary with the type of data you're loading or storing, the set of permissible immediate values (an eight-bit value shifted by an even number of bits), and an obnoxious constraint on operands of multiply instructions.

      Of course, writing code for the ARM is heaven in comparison with writing x86 code, but I would not say it is all that spiffy in comparison with 68xxx or PowerPC.

  7. To those who think assembly is irrelevant by Mr+Z · · Score: 5, Informative

    One thing I've noticed in the comments attached to this article is the repeated question: "Is assembly still relevant?" As someone who codes assembly on a regular basis, I must shout an unequivocal YES.

    It's relevant on many levels. First, as another posted has pointed out, learning assembly is very similar to an EE learning circuit theory: To really understand the aggregate effects, you sometimes need to understand the details. Now, one could counter "But Physics isn't taught that way!" You're right, but then Physics 1 (kinematics) and to a large extent, Physics 2 (electricity and magnetism) is much more concrete than anything you'll ever learn programming-wise. Also, the "approximations" provided by Newtonian mechanics fairly accurately describe nearly all of what most of us will ever interact with. The rest of us take one or more Modern Physics courses that cover quantum mechanics and all the other nitty-gritty.

    On another level, it truly does allow you to get away from the noise of the language and concentrate on what the machine really does. I've seen so many people that are so out-of-touch with their code, it's unreal. Even in C, it's easy to write code with way-too-much hidden complexity. If you understand assembler, though, you're more likely to think about the true cost of each action. At the very least, you're much more likely to be able to compile to assembly output and actually understand what you're looking at.

    I work in embedded systems, and in that space, assembly language hasn't died. I program DSPs for a living. While high-level languages are continuing to absorb ever larger chunks of code in this space, it seems as though assembly will still always rule the tight loop. If nothing else, it's an invaluable measuring stick for knowing just how close or how far from ideal you really are.

    So in summary, assembly language is still relevant. It's the only way to truly be demystified about how your code actually gets executed. And it's a great way to get programmers thinking about all the levels of abstraction when the time comes.

    --Joe
  8. Tossing my hat into the lot... by Cutriss · · Score: 3, Interesting

    I think Irvine's text was a good middle-of-the-road read. Duntemann's "Assembly Step By Step" was very informative and helped me learn some more varied aspects of assembly which Irvine's text was a bit short-sighted with...but otherwise, for a college textbook, it's head and shoulders above many others I've read. Uffenbeck, anyone?

    The first time I took Microprocessors, my instructor actually recommended that we use Uffenbeck's text to learn x86 ASM. Thankfully, when I retook the course, we had Irvine's text to accompany it. Don't get me wrong...Uffenbeck's book is good for comparative architecture analysis and the hardware side of things, but it's useless for learning ASM programming.

    --
    "Mod, mod, mod...and another troll bites the dust."
  9. Re:Love/Hate relationship by scotch · · Score: 3, Funny

    Furthermore, if most of the people the poster knows have such a relationship with this book, he has an extremely limited range of acquaintenances. The poster would be served well to meet and socialize with people outside the computer field.

    --
    XML causes global warming.
  10. Academic Pricing sham by mstrcat · · Score: 5, Interesting

    Using one of my favorite shopping bots to price this book,

    http://www.bestbookdeal.com/cgi-bin/prices.cgi?i sb n=0130910139

    I noticed once again that the UK price is about 2/3 the US cost. So it's cheaper to buy the book in the UK, and have it air-mailed across the pond than it is to buy the new book here in the states. This is not an isolated incident, but a systematic one. As a Masters student, I regularly find that UK textbooks are frequently about 1/2 the US price.

    This smacks of price fixing by the publishing industry, akin to what we see the movie industry doing with movies.
    Can anyone comment on how prices for US books are set and how much business they lose to people using the Internet to shop internationally?