Slashdot Log In
Assembly Language for Intel-Based Computers, 4th edition
from the heavy-reading-about-weightless-components dept.
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.
Parent
Re:Assembler is hard to follow? (Score:2, Insightful)
Well, I can mostly only speak for MIPS assembly, but that's very far from the hideous gothic nastiness of x86 - it's just like an 8-bit micro (esp Z80) just with bigger registers and more of 'em.
Some details (it's been a while) that I can remember are:
Once you've gotten used to some of MIPS' ideosyncracies (mandatory data alignment, branch-delay slots, having to reinterpret excepted branches in software) then it's just like the good old 6502 days.
I have less experience of PPC, SPARC, and ARM, but all are similar - clean feeling, but each with a few wacky RISC wrinkles.
Death to x86
Re:Assembler is hard to follow? (Score:3, Funny)
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.
Re:Assembler is hard to follow? (Score:2)
Okay, how about "rococo"?
ARM (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 [gbadev.org].
Re:ARM (Score:3, Informative)
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.
The 6502 Lives! (Score:2, Interesting)
When he started the class, he used Apple IIs. School wouldn't keep these around just for one class, so now he uses an Apple II emulator running on PCs.
Ahh...memories (Score:4, Insightful)
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?
Parent
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]
Re:Yet another assembly book outdated at release (Score:2)
Introductory assembly is often taught in DOS because the examples tend to be quite simple. As for IA-64, it really doesn't belong in this book - the book is for teaching x86 assembly. If you're going to include IA-64, you may as well include Sparc or Alpha as well. Besides which there is really no reason to program an IA-64 in assembly. The compiler is going to beat you every time.
not only is the compiler going to beat you (Score:2)
Focus, Title (Score:2)
Omitting Linux makes a book a little more narrow than some of us would like, but that doesn't make it obsolete it either. Last time I looked, there were one or two Windows programmers gainfully employed.
So the title is misleading. Probably chosen by the publisher, after they decided that an accurate title ("IA-32 programming for Windows and DOS"?) wouldn't sell. And it doesn't cover topics some (but not most) of us are interested in. Sounds like 90% of the computer books in print.
I've been looking at Chapter 1 of Duntemann's book [amazon.com] Fourteen pages of lame jokes, complicated metaphors, and totally redundant explanations of basic programming concepts. (Everybody who doesn't know what a loop is, raise your hand!) The first serious technical information is in chapter 2, where he explains non-decimal math by presenting a table labeled "Counting in Martian, base fooby." (Xip means 0, foo means 1 .. foobity-barby-foo means 25) OK, maybe you think this is very witty, but it all goes by most of us. And separating the technical detail from the hyperactive comedy requires more energy than a serious student can spare.
Re:Focus, Title (Score:2, Informative)
But those people could jmp along to :
Re:Yet another assembly book outdated at release (Score:3, Informative)
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).
Re:Yet another assembly book outdated at release (Score:2)
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.
Description of the FAT (Score:2, Interesting)
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:3, Interesting)
Its aslo handy to know for embedded systems.
Also, I used Kip's book and I fall into the 'cool book' catagory
Re:A lost art, alas (Score:2)
When I entered my university I took an advanced pascal class (still a 100 level course, first year) which introduced us to dynamic memory allocation, strings, dereferenceing, etc. I was lost. I spent half the time throwing the dereference character (^ IIRC) in front of variables just to see if it worked... I think I came out of there with a C or C+ (maybe a C-).
The next semester we took assembly programming, and wow, everything suddenly made sense! Understanding exactly *what* a pointer is, and how it and dereferencing really works was a huge boost to my understanding of programming, and computers in general. It could be that the advanced pascal teacher didn't do a good job, or that I was just a slacker that year, but ASM gives a huge boost to the understanding of how computers work.
Re:A lost art, alas (Score:3, Insightful)
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.
Re:A lost art, alas (Score:2)
I would not want to see what would happen if you taught them assembly first. I have seen one college in Ontario, Canada that teaches assembly in their CMP program in the last semester.
CPA program (Score:2)
siri
Re:A lost art, alas (Score:3, Interesting)
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.
Re:A lost art, alas (Score:3, Interesting)
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.
Re:A lost art, alas (Score:2)
The only reason I've ever held my head above water in the programming sphere is because my first languages were BASIC and Assembly.
Actually, it's interesting, but the BASIC language is similar to assembly, in a way, inasmuch as it is a list of instructions to be executed in order. If you want to arse around from one section of the program to the other, you yourself have to goto and figure out how to get the hell back (well, you have gosub, but you get the idea). From that background, assembly was a dead cinch.
I actually wish I'd learned more and more and more about the absolute fundamentals of computer science - lamenting the fact that my first exposures to computers wasn't to something with punch cards or front panel switches and lights.
Re:A lost art, alas (Score:2)
Other people might feel that Forth was a better language -- having just enough abstraction to allow some modularity, but only barely. Nearly all virtual machines look like Forth machines... I suppose that implies that computer scientists disagree with electrical engineers as to how a machine should act.
Re:A lost art, alas (Score:2)
All algorithm theory should be taught in assembly.
Out of curiosity...what kind of crap school did you go to? We didn't program at all during my algorithm theory class. We did math. That's what algorithms are. Assembly is just a layer of cruft on top of the math.
Re:A lost art, alas (Score:2)
Other classes that I took that I would highly recommend to anyone else studying Computer Science. Operating Systems, Compilers, Comparative Languages, Artificial Intelligence.
Sure, Assembly is tough. It is unforgiving and you know what? It is a good thing to learn the proper way to do things. High level languages make it easy for people to program a computer. They also make it easy to program a computer badly.
Program a computer badly in assembly and you generally don't get the desired results.
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.Parent
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.
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.
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.
Re:Windows (Score:2, Offtopic)
So, int 21 does what on linux? What about int 2e on DOS or Linux?
Re:Windows (Score:2)
Those were software interrupts used to access the umbrella interrupts of DOS/BIOS. AFAIK, Linux does not use the BIOS interrupts.
Re:Windows (Score:2)
It's interesting that for all practical purposes, the IBM operating system prior to Windows 95 was the BIOS. DOS was nothing more than a shell; the BIOS did everything. Somehow, though, the BIOS was reverse-engineered (almost immediately) and became a commodity, while DOS never had a serious competitor. DOS launched Microsoft; IBM backed out of the PC market (for a while).
Re:Windows (Score:2)
Really? So what BIOS call allocates memory for me? Or writes files to disk? Or lets my program go TSR? Or lets me write "$" terminated strings to screen? (ok forget that one. Whoever came up with THAT idea in the first place?)
The BIOS only provides easy access to some default hardware like the screen and the harddisk, but it has no knowledge at all about the filesystem or things like that. That's what io.sys does.
Re:Windows (Score:2)
DOS was implemented in BIOS calls. It was a completely "userspace" application. It could be replaced by (bootable) applications, such as games, which were willing to manage their own files.
Re:WTF? (Score:2)
Think about it (and it was mentioned in the review as well)
int main(int argc,char **argv)
{
printf("hello world");
}
is largely OS agnostic.
Now, do the same in OS agnostic assembly.
OK, so console I/O was unfair. How about:
{
int *x = new int[20];
delete [] x;
}
Re:PPC Assembly (Score:2)
our compiler has an affinity for the RLINM (rotate left AND mask) where it rotates for ZERO and masks with xFFFFFFFF. I guess simply storing a number into gpr23 wasn't fancy enough.
Also, IBM has some assy manuals for AIX. I use a 32 bit POWER architecture (as one could glean from the hex number above), but I think they have the PPC ones online (came in handy with my powermac at home)
also a quickie link: right here [ibm.com]
Re:PPC Assembly (Score:2)
Re:PPC Assembly (Score:2)
Comnbine that with the manual that says what the hack an rlinm is, and you have enough to shed a LEEETLE bit of light. Not enough to make it easy, but enough to help the dogged developer/problem determinator.
Re:PPC Assembly (Score:2, Informative)
Not a book, but a good intro at Developerworks: PowerPC assembly [ibm.com]
Re:PPC Assembly (Score:2, Informative)
http://www-3.ibm.com/chips/techlib/techlib.nsf/
Re:Love/Hate relationship (Score:3, Funny)