Slashdot Log In
Assembly Language for Intel-Based Computers, 4th edition
from the heavy-reading-about-weightless-components dept.
| 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.
Assembler is hard to follow? (Score:2, Funny)
Re:Assembler is hard to follow? (Score:4, Insightful)
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.
Ahh...memories (Score:4, Insightful)
PPC Assembly (Score:1)
ebay half.com has it for lots less $ (Score:2, Informative)
Academic Pricing sham (Score:5, Interesting)
http://www.bestbookdeal.com/cgi-bin/prices.cgi?
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?
Yet another assembly book outdated at release (Score:4, Informative)
If you are looking for a assembly book that is fun to read and goes into Linux details try: "Assembly Language Step by Step" [duntemann.com]
advanced topics? (Score:2, Interesting)
Things like real-mode and protected mode programming would have been far nicer to see,
Advanced topics should be Ring(0-4), Virtual Memory and paging, PCI address space mapping and APIC.
I learned ASM from... (Score:1)
The old texts and demo tutes.
And 'tute' isn't something you do with your horn.
Description of the FAT (Score:2, Interesting)
I didn't read it either (Score:1)
Hmm...
hmmm (Score:1)
from my own, brief, experience with assembly language, i was under the impression that its role as an instructional aid largely consisted of the following:
If only it could all be like 6502 assembly (Score:1)
-History shows again and again... how nature points out the folly of man- GODZILLA!
A lost art, alas (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.
Re:A lost art, alas (Score:5, Interesting)
- 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.Love/Hate relationship (Score:1, Offtopic)
That's not a love/hate relationship. A love/hate relationship would be "I used it, it was hard to follow, but I learned Assembly once I finished wading through it. I'm glad I read it, but if I have to do it again, I'm going to commit Hari-Kari"
Third addition has more appendices (Score:2)
Incidentally we're not doing hello world at all, or any other examples from the book. At this point the only reason we even have the book is for the list of registers; We haven't been working out of it at all, and I don't feel the loss. When I go to look at the book it doesn't seem to follow any kind of reasonable pattern -- By which I mean "this is some code, this is what it does, this is why it does it". Then after giving that basic introduction it should expand on why each thing works as it does in various chapters. This is the kind of layout that makes sense for a textbook.
not a good book to start from (Score:1)
Embedded Kits..... (Score:1)
Small rant on ``Assembly rules'' dudes (Score:1)
I'd really love to see a complex distributed network application written in pure Assembly. Then I'd change the spec just a little, just to show the total lack of robustness and flexibility that app would have.
Hardware people tend to think that the fact that you execute your program on hardware matters. I think not. Software lives on its own, you need to be able to abstract the fact that you are running on hardware if you want to be able to manage the complexity.
Used this book (Score:1)
To those who think assembly is irrelevant (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.
--JoeTossing my hat into the lot... (Score:3, Interesting)
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.
Short, but sweet... (Score:1)
The book was well done with lots of examples, but I didn't quite catch on. Not by fault of the teaching materials, but for the topic. I personally found Intel Assembly pretty confusing.
I corroborated this by taking another class next term, which was based on Motorola 68HC11A8 Assembly, and it was a lot easier to understand.
Just a quick peek into X college student's mind...
Compiler? (Score:1)
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,
I would lie to you if I told you that I've read the whole book.
It would also seem you would be lying if you said you made it to Chapter 1 -- Basic Concepts, deep into the text on page 3 where it says:
" What is an assembler? "
Hint: Not a compiler.
asmutils - assembly on Linux (Score:2, Informative)
I used to do some assembly back in the DOS days and keep meaning to have a look again sometime.
MASM within Bochs/FreeDOS Emulation (Score:2)
I am wondering if anybody has any experience with MASM, especially attempting to run it on any DOS running within a virtual machine. I am trying to create an easy platform for Linux and Mac students in my class in order to learn ASM without the need for Windows (grader will only test our project assignments in MASM).
http://videl.ics.hawaii.edu/bb/viewtopic.php?t=2 [hawaii.edu]
I had attempted to run MASM on FreeDOS running on the Bochs Pentium Emulator in Linux, but it crashed. You can read about these problems at this address.
I am not fully understanding about the capabilities of MASM in FreeDOS, especially within a Bochs environment. I suspect that Bochs or FreeDOS cannot support some features that MASM needs, or some of the coding requirements needed for my class this semester. I realize this question is a bit vague, though I would appreciate any insight into these problems.
Alternatively, would there be any other 99.9%+ MASM compatible assembler that is free or Linux based? What problems may I run into with the other assemblers?
Somebody else had mentioned trying DRDOS because that has become free (beer or speech?). Does anyone have any experience with DRDOS and MASM instead? Where can I get this?
Thanks,
Warren Togami
warren@togami.com
Mid-Pacific Linux Users Group
http://www.mplug.org
p.s.t all.php
[mplug.org]
http://www.mplug.org/archive/2002/bochs_win98_ins
Here's one cool though unrelated screenshot of Bochs running the Win98 Installer in Linux. Bochs isn't nearly as fast or stable as VMWare, but it is free and Open Source, and runs on other platforms like PowerPC.
V2OS (Score:2)
I haven't played with it in a long time, but it looks like it's come along by leaps and bounds. The first demo used somewhere around 50 K of floppy space and encompassed a kernel, filesystem, networking, and some basic tools. It appears that there's a stronger application base now, and it probably still sits on a floppy.
helpful (Score:1)
Books To Learn Assembly? (Score:2, Funny)
No wonder our education system is going down the tubes!
WHOA! (Score:1)
Non MS-DOS/Windows book (Score:2)
Chris
Hey, there's Java over here! (Score:1)
Assembly might be fast etc. but it simply to dated and machine specific to be useful.
One thing that surprises me with open-source is the fact that there is very little support in the community for java. This is after all the language that could make Windows apps work on Linux without any extra work.
And to be honest what's best: spending an extra 200$ on a faster computer (to make up for the slowness in java) and being able to run Photoshop etc, or sitting around with a dopey P200 and running those cute-but-fast Linux programs.
- Waiting for Xandros
If you're really nostalgic about Assembler.... (Score:1)
If you want you can code directly in PASM [parrotcode.org] (Parrot Assembler) or help write some of the tools that parse real languages and emit PASM. It's not a particularly small assembler like 6502 (but it can be if you really want!) but still has that small-system feel.
I got my Assembler fix this past spring with Parrot BASIC [theperlreview.com] (link is PDF).
What if you already know assembly programming (Score:1)
I've done extensive assembly language programming for Z-80, and small to moderate amounts for 68000, PDP-10, PDP-11, VAX, and Alpha, but managed to avoid the x86 until I took my current job. Here most of what I do is well above the assembly level, but it would occasionally help to be fluent in x86 assembler.
I suppose the answer is to just read over code with the Intel manuals in hand to look things up, until I get to where I don't have to look up so much anymore. But I was hoping for something less tedious.
What about a book on AT&T assembly ? (Score:2)
if you think assembly is useless... (Score:1)
x86 assembly is a bad teaching language (Score:2, Interesting)
Our assembly class was based on some invention of the professor's. It used a virtual machine and its own language. It probably would have been better to use something like z80, but it was okay. For me the class was rather pointless except for the project to write an assembler.
We used the Hennessy book for architecture which is of course MIPS based. I thought that was a great assembly language for learning RISC and stuff like pipelining.
After college I taught myself Motorola 68k assembly. Wow! That is the most elegant assembly language I've ever used. x86 assembly in contrast is very odd and clunky. I'm curious what PPC is like, but I haven't studied it.
For Computer Science I think it is better to learn the general concepts such as memory hierarchies, superscalar design and pipelining, etc., and focus on generic 32 bit RISC architecture. I think that will serve students far better than learning x86.
If you're not motivated enough to learn any specific language, assembly or otherwise, on your own anyway, I think you're in the wrong field!
-Kevin
Why learn assembly? (Score:1)
Free alternative (Score:2)
Re:Windows (Score:1)
the x86 command set doesn't magically change just because you installed linux. There's no such thing as 'OS specific' assembler.
It's just that DOS/Windows makes good use of assembly, and being an x86 platform, is of much more use.
Linux isn't solely an x86 platform, so assembly is of much less use (if any at all) when you want your code to compile on a mac/ARM/MIPS etc;
Bah, why bother
Re:Assembly: Why it will replace C++/Java (Score:1)