Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Book Reviews IT Technology

Assembly Language for Intel-Based Computers, 4th edition 255

Posted by timothy from the heavy-reading-about-weightless-components dept.
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.
This discussion has been archived. No new comments can be posted.

Assembly Language for Intel-Based Computers, 4th edition More

Assembly Language for Intel-Based Computers, 4th edition

Comments Filter:
  • Maybe that's why the book is hard to follow too. I quit at 6502. I gave up after that.

    • Re:Assembler is hard to follow? (Score:4, Insightful)

      by Amazing Quantum Man ( 458715 ) on Wednesday September 04, 2002 @11:40AM (#4195315) Homepage
      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.
      • Not to mention the old Vax asssembly language, which is about as easty to learn as C, and not difficult at all to make reasonably maintainable code with.
      • > and probably most RISCs, too

        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:

        • No "special" registers - they're all stored as offboard registers on one of a number of "coprocessors". This is true even for FP registers.
        • Highly symetrical instruction set.
        • Doesn't enforce register conventions - stack-pointer, short-pointer, parameter-pointers and return addr are all just an optional convention, not baked into the chip.

        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

      • > 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.

      • ARM (Score:3, Interesting)

        by yerricde ( 125198 )

        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)

          by jejones ( 115979 )
          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.
    • I'd rather be skinned alive than use Assembler. It reminds me of the dark days of Jurassic programming in the 70's when punch cards and rubber couplings roamed the just-cooled Earth. I'd MV away and PUSH a shopping cart while I POP a few cold beers before I JMP back to those days. The work just doesn't CMP to today.


      God I had a hard time remembering those. That's good.

    • The 6502 Lives! (Score:2, Interesting)

      by fm6 ( 162816 )
      Hey, I have a friend who teaches a 6502 assember class at a local community college. Quite well-attended. I doubt if any of his students use this skill in real life, but it is a good way to pick up basic computer architecture.

      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)

    by NPE ( 595798 ) on Wednesday September 04, 2002 @11:40AM (#4195316)
    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.
  • Can anyone recommend a good book for learning 32bit PPC assember?
    • compiling with the -a (or -s) option to produce assy code. Especially wicked in combination with the -o optimization option!

      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]

      • That would seem to leave something to be desired in the way of a tutorial. ;+) Unless of course, the assembler is capable of adding intelligent commentary. Hmmph...
        • The closest thing you get to intelligent commentary is "line numbers" where these 20 lines of assy are related to this one line of C or ADA or whatever.

          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)

      by Tomy ( 34647 )

      Not a book, but a good intro at Developerworks: PowerPC assembly [ibm.com]

    • Re:PPC Assembly (Score:2, Informative)

      by YeahIThoughtSo ( 415635 )
      Try the user manuals found here:

      http://www-3.ibm.com/chips/techlib/techlib.nsf/p ro ducts/PowerPC_750CX_and_750CXe_Microprocessor

  • http://half.ebay.com/search/search.jsp?nthTime=2&p roduct=books&query=Assembly+Language

    • Academic Pricing sham (Score:5, Interesting)

      by mstrcat ( 517519 ) on Wednesday September 04, 2002 @01:52PM (#4195993)
      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?
      • It isn't price fixing, it's price discrimination. Obviously the folks in the UK have more elastic demand than we do over here, so the enterprising monopolist (that's what copyright's all about, you know) sets a different price in the two markets to maximize his revenue.

        British publishers make their textbooks available in India at 1/5th to 1/10th the price they charge in Britain, I'm told. It isn't charity, it's profit maximizimg behavior. If you are comfortable with chinese, you can get the chinese edition of many books for $2 to $5 US.

  • Yet another assembly book outdated at release (Score:4, Informative)

    by ehiris ( 214677 ) on Wednesday September 04, 2002 @11:41AM (#4195326) Homepage
    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" [duntemann.com]
    • I don't see any mention of IA-64 or Unix/Linux ...

      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.

      • It's the only real choice for any app of significant size. Your assembly code will be unlikely to work at all on any significantly-sized app, because of the incredibly complexities of IA-64's pipelining (to improve speed, they took out all the "make sure stuff gets executed in the right order when we parallelize" hardware, so it's up to the software to take care of that now).
    • The word Linux does appeare in the book. On page 6 there's a discussion on why learn assembly language.
      One of Irvine's bullet points is about creating device drivers.
      Here's a snippet... Printer manufacturers, for example, create a different MS-Windows device driver for each model they sell. The same is true for Mac OS, Linux, and other operating systems.
      At Cleveland State this year we had to buy this book and another (can't remeber the name it's used the second half of the semester) for the Lanugage Processor class.
      If you want IA-64 info go to Intel's site [intel.com] for the white papers. :)
    • According to the preface [nuvisionmiami.com] (warning, PDF file) this is strictly an IA-32 book. Which doesn't make it obsolete. Quite the contrary -- it'll be a long time before more assembly-language programming is done for Itaniums than for Pentiums and their clones. If ever.

      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.

    • 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).
      • Sorry it didn't float your boat. People seem to either love my book or hate it, but it's been in print for 13 years and my mail pile seems to think it succeeds for way more people than it fails.

        A lot of people forget that this book has a gimmick: It's assembly for people who have never programmed before and know *nothing* about programming with *any* language. My experience tells me that people who learn the underlying machine before they get too caught up in data structures do better when they have to battle two hundred diverse APIs in the same project, which is the way things have gone in Windows and are headed in Linux.

        People who know something about programming and about the fundamental nature of computing should skip the first couple of chapters.

        The next time I rewrite it (and that's going to be awhile still, maybe another year) I'm dropping DOS entirely, and will rewrite it for Linux from one end to the other. I will also teach people how to make kernel calls and not apologize for it. If all you do with assembly is call clib, you might as well use gcc. Assembly really is its own language, with its own culture and assumptions and ways of going about things. It is *not* C, and thank God for that much.

        I may also drop the foobies thing in the next edition. The mail's been mixed on that--though I'm still trying to think of a good way to teach hex to those for whom number bases other than 10 are a serious mental roadblock.

        Thanks, by the way, for the mention here on Slashdot. The book's been around for quite a few years and doesn't get much press anymore, even though it continues to sell well.

        --73--

        --Jeff Duntemann
        Scottsdale, Arizona
        (jeff at duntemann dot com)
        • Jeff--

          Hate to be the bearer of bad news, but the book didn't work for me, either. But that's okay; you still get props in my book for writing the text that helped wrap my head around Pascal way back when. There, I'm done being a fanboy; the rest of this is all for Slashdotters without a clue.

          Clue: when all is said and done, it doesn't matter if one particular book helped you or didn't help you. It doesn't matter if one particular kernel patch lets you use your FooBarBaz card, or if it just sets your mobo on fire.

          What matters is what you do about it. If you read a great book on Assembly and then sit on your ass and don't do anything with that knowledge, then you might as well have not read the book in the first place. If you read a lousy book on Assembly and decide "dammit, there needs to be a better book," and then write that better book, then congratulations: you matter.

          It's easy to say that the fellow who's actually doing the job could, should, be doing it better. (Hell, that sounds pretty much like John C. Dvorak's job description.) But it's a much harder thing, and better thing, to actually do the thing.

          Like the old saw goes: shut up and code.

  • advanced topics? (Score:2, Interesting)

    by oliverthered ( 187439 )
    Unless you doing task switching MMX etc... then there's nothing that advanced in FP specificly.

    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.

  • The old texts and demo tutes.

    And 'tute' isn't something you do with your horn.
  • I used this book in college for learning assembly. Still have it on the shelf. I was doing some work on FAT and partition tables recently and was able to quickly get the information I needed from this book. It wasn't in depth, but I didn't read more than two pages before I was on my way. Wish it was that easy back in the college days!
  • I would lie to you if I told you that I've read the whole book.


    Hmm...

  • 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:
    "don't do that again , or i'll hit you with this book a
    second time...!"
  • Ah... I loved programming my Commodore 128. Assembly was the only way to go. I don't see the point though learning on a x86, at least for application programmers.

    -History shows again and again... how nature points out the folly of man- GODZILLA!

  • A lost art, alas (Score:5, Insightful)

    by Reality Master 101 ( 179095 ) <RealityMaster101@gmail. c o m> on Wednesday September 04, 2002 @12:00PM (#4195391) Homepage Journal

    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)

      by Your_Mom ( 94238 )
      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
      • I don't know if I can vouch for everything being taught in ASM for the first while, but I can definately attest to the fact that learning assembler was a huge boost for me.

        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.
    • I hear what you're saying, and part of my agrees wholeheartedly. I learned assembler first in school before moving up to higher level languages. However, in this day and age is there really a need for people to learn it? I mean it gives them a far better understanding of what their computer's actually doing, but people don't want to bother learning the low level stuff that they'll never directly work with. It's easier and cheaper to jump to learn to the high level languages like C, VB, Java, and whatnot.

      Another perspective on that is if I were just starting schooling now, do I want to waste a year learning archaic languages? In this industry a year is a LONG time to be sitting around not learning what will get you jobs.

      Just my 2c. :P

      • However, in this day and age is there really a need for people to learn it?

        If they want to be anything above mediocre, I believe so.

        I mean it gives them a far better understanding of what their computer's actually doing, but people don't want to bother learning the low level stuff that they'll never directly work with. It's easier and cheaper to jump to learn to the high level languages like C, VB, Java, and whatnot.

        Of course, but just because it's easier and cheaper doesn't obviate the need for a deep and fundamental understanding of the way computers actually work. Like it or not, every programming language is a fancy assembly language with some more abstraction layered on top, and regardless of how much "background information" is given in the class, it's going to make much more sense if the student actually works in some assembly language for a little while. It doesn't matter which, and the student doesn't have to become an expert, but how else to explain, for example, that certain operations will be more costly than others, without knowing what an opcode is?

        I'd like to take issue with several of your comments, by the way. I don't think it's "easier" by any means to skip learning some assembly. My current programming experience is continually enriched by what I learned from my real-mode x86 days, and I'm sure if I took the time to learn modern protected-mode techniques I'd be able to understand some of the Linux error messages and such a little better. The more you know as background information, the less time it should take to figure out a particular solution, and if time is money, it's certainly not "cheaper" to skip it either.

        C isn't "high level", either. It's a portable assembly language.

      • Another perspective on that is if I were just starting schooling now, do I want to waste a year learning archaic languages? In this industry a year is a LONG time to be sitting around not learning what will get you jobs.

        Are you at a college or a vo-tech school? If you learn the principles of programming, then the language doesn't matter so much after awhile. You need to learn different programming paradigms, but once you do, then the specifics of syntax aren't as big a deal.

        At a vo-tech type of school, you're there to pick up specific skills to allow you to target a narrow range of jobs. At a college, you're there to pick up general skill sets and ways of thinking about problems that can be adapted to many jobs.

        I consider understanding assembly language to be one of the basic fundamental concepts that helps unify all the abstractions we heap on top of it. If programming languages always just seem like magic to you, you'll never truly understand what you're doing. Good luck generalizing what you learn if you don't know what your code looks like on a couple different levels of abstraction.

        --Joe

      • Re:A lost art, alas (Score:5, Interesting)

        by jandrese ( 485 ) <kensama@vt.edu> on Wednesday September 04, 2002 @12:55PM (#4195665) Homepage Journal
        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.
      • If you know 'what' the computer is doing your going to write faster less bloated code be able to track down bugs easier and have a more logical approach.

        Why strings, well high level strings are usually the slowest most bloated things you could care to mention.

        as a sudo example of bad string use

        string mysting = 'larlarlarlar'
        while(mystring.length>0)
        begin

        string astringthatwontchange = mystring.leftchars(4)
        mysting =mysting.rightchars(mysting.length-4)

        dosomethingbasedon(astringthatwontchange)

        end

        if you don't know whats going on you won't realise that you can use a head-tail index instead and avoid copying and alloacating all that memory &co.

    • Re:A lost art, alas (Score:3, Insightful)

      by Hard_Code ( 49548 )
      "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.
    • The college I went to (note: college is supposted to be practical, whereas university is supposted to be higher level theory - at least in Canada, they aren't the same here) has a 'CPA' program designed so that people could be taken off the street. Some of those students had trouble picking up Java and VB. Most of them got it after a while.

      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.
      • Well I wouldnt expect my accountant to bust out even a little simple perl code, so why are they worried about them handling Java and VB?

        siri

    • Re:A lost art, alas (Score:1)

      by Anonymous Coward
      EEs become better programmers than those who start out as programmers because of that second 'E' in "EE": Engineer. It's a whole way of thinking that can't be self-taught with a VIC-20 and a BASIC manual.

      Unfortunately your reasoning about assembly is wrong. Voltage, current, resistance, inductance etc. are principles that apply to everything an EE is going to do and they must be known before doing the high level stuff. Algorithms are the corresponding general principles of computer science and are best represented in high level languages. Having to think about whether a register is 4 or 8 or 16 or 20 or 32 bits is just a waste of time in that case and basing implementations on that knowledge is asking for trouble. That's why C is often called portable... (unless you're a nutcase named Scott Nudds, but I digress).

      Anonymous, because I'm sure there are moderators out there that resent not being real engineers.

    • Re:A lost art, alas (Score:3, Interesting)

      by sydb ( 176695 )
      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.

    • Re:A lost art, alas (Score:1)

      by Anonymous Coward
      Couldn't agree more.

      I'm an EE who spend most of my time coding in C (used to do 6502, Z80, 68K and X86). I did really well at CS at secondary school (11-16), but concluded that that taking it any further was a waste of time. There were a lot of people taking CS at higher levels that really shouldn't have been there. I took Electrical/Electronic Engineering because it was more challenging, though I think my life would have been easier if taken CS instead.

      At the end of the day you have to have an aptitude to work in this field, some people just don't have it.

    • 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.

    • I'm in TOTAL agreement.

      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.
    • Assembly language should be the FIRST thing taught, and then gradually building up to higher and higher levels of abstraction.
      Assembly isn't necessarily the most fundamental level. Sure, it is for one particular computer (in a way -- pure machine code is slightly more fundamental). But you can go lower, if you see it as a mathematical, not electrical, excercise. Maybe the first two years should be taught using Turing Machines, or with the lambda calculus?

      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.

    • Did you spend two years learning lambda calculus before you were allowed to program?

      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.
    • Computer Science at my college required both Assemblers and Introduction to Computer Engineering. We had to build a 4 bit computer out of chips and wires on a breadboard and then demonstrate it working to do math operations. Then we had to program it to do operations that were not wired into it.

      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.
    • I completely agree.

      My history of languages learnt are (roughly):

      1. Spectrum BASIC [madhippy.com]
      2. Z80 Assembler
      3. 68000 Assembler (on my Sinclair QL [madhippy.com])
      4. POP-11 [poplog.org]
      5. Prolog [poplog.org]
      6. Standard ML [poplog.org]
      7. Modula-2 [google.com]
      8. C
      9. C++

      Not including shell scripting languages etc.

      I'm now a Senior Software Engineer working almost exclusively in C++ and I feel my varied history of languages learnt has greatly contributed to making me the seasoned professional I now am.

      The finer point I'm trying to make is that I've engineered C/C++ on boxes ranging in size from clusters of 4GB RAM, 8 x 1GHz POWER4 CPU RS6000 AIX machines all the way down to mobile phones and I feel learning a couple of assembly languages was an appropriate and valuable part of my personal development as a Software Engineer.

    • All algorithm theory should be taught in assembly.

      I'm sooooo tempted to believe I've just been trolled, but what the hey. First off, algorithmic theory is typically taught in terms of turing machines -- if that's not low-level enough for you, I don't know what is. Beyond that though, you're absolutely wrong. It's like teaching the physics concepts of torque by making students work on cars.

      Look at the way EE's are taught

      Not relevant. This is not EE. You might have had a point with respect to software engineering (and I'm not even sure then). Dijkstra 's rolling in his grave, though he was certainly fretting about this awful conflation of CSC with engineering long before then.

      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.

      One reason is that most EE degree programs are hard. People who finish an EE degree are often just plain more determined and better problem solvers as a result, because the CS curriculum is just not made challenging enough -- partly because it's still such a new field.

      Look, you want a better office suite or HRIS system or oil exploration mapper, you hire a programmer. You want a new font optimization, dataflow model, or signal analysis method, you hire a CS person (the last being something an EE person would probably shine at too). God forbid you should get a CS person who can only think in terms of a particular machine design.
  • "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.'"

    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"
    • 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.
  • I'm in a course using this book at my college and the instructor says that there are like four removed appendices between third and fourth editions. This is lame.

    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.

  • I've got the third edition as a reference work, and decided not to buy the fourth as it's rather expensive for a replacement edition. (nothing bad happened to IA32 asm in the meanwhile ;) ) But i'll have to say it's not really a good book to learn IA32 from if you start more or less from scratch. I learned asm with the 6502 and Z80 (long after they were hip btw, i was a bit of late bloomer asm-wise) instruction sets. But if you more or less master those simpler (yet still complicated for a starter) to program processors you will have gained insights in the elementary asm procedures that will make learning from or reading a book like the one Irvine wrote. So let's hope somebody really writes a good coursebook which starts teaching on a simple 6502 virtual machine and then moves on to the stuff you really want to learn about the IA32. But that's a task some good tech writer (like Irvine is btw, kudos to him) has to take up.
  • Before everyone goes on a rampage about how old assembler is and how they could care less of its existence. Keep in mind the embedded developers. My first cut was on an 80188 and I couldn't of lived without it for some of my projects...
  • Some people seems to think that programming is only about algorithms, and fast execution of those. But programs are ``algorithms + data''. Programming in assembly lose you all your flexibility when dealing with data.

    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.

  • I used the 3rd edition for my assembly class a year or so ago. Didn't reference the book that much. The instructor provided decent notes online and I mainly used them. Used the book to find similar examples to homework problems. I have since tried reading the book but have gotten bored each time and forgotten about it. I wish the book didnt focus so much on the microsoft world but what can you expect. I wish it focused more on direct hardware access which is what i see assembly being more usefull for.

  • To those who think assembly is irrelevant (Score:5, Informative)

    by Mr Z ( 6791 ) on Wednesday September 04, 2002 @01:00PM (#4195707) Homepage Journal

    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

  • Tossing my hat into the lot... (Score:3, Interesting)

    by Cutriss ( 262920 ) on Wednesday September 04, 2002 @01:06PM (#4195732) Homepage
    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.
  • There is a project at http://linuxassembly.org/asmutils.html [linuxassembly.org] where they're writing some of the standard UNIX utilities in x86 assembly. It's used for things like floppy distributions such as tomsrtbt.

    I used to do some assembly back in the DOS days and keep meaning to have a look again sometime.
  • I'm currently taking ICS312 at the University of Hawaii where we are required to use Microsoft Assembler (MASM) and this exact book for our coding projects. This book comes with MASM 6.15 for Windows, and MASM 6.14 for DOS.

    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.
    http://www.mplug.org/archive/2002/bochs_win98_inst all.php [mplug.org]
    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)

    by Lxy ( 80823 )
    If you like assembly, and think small, fast code is cool, check out V2OS [v2os.cx] (or better yet, contribute code!).

    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.
  • Heck when I was your age we used brains and thinking to reverse engineer what the asembly instructions did..

    No wonder our education system is going down the tubes!
  • For those without access to an x86 machine, but who do have access to a Sun box, I can wholeheartedly recommend "SPARC Architecture, Assembly Programming, and C" by Paul. I learnt assembly programming from it, then x86 assembly with NASM and a PDF I found on the web. The SPARC architecture seems much more coherent, and Paul's book was actually an enjoyable read - not what I ever expected to say about a book on assembly language programming.

    Chris
  • I'd really like to be able to read the output of gcc, but most assembly language books deal with Intel syntax, while gcc outputs AT&T syntax. Are there any decent books for someone interested in reading gcc output ?
  • I'd done a small amount of 6510 (gradeschool) and x86 (high school) programming before I took assembly language and computer architecture in college.

    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

  • Those wishing to dig into Intel assembly language without shelling out seventy-some-odd bucks can download the PDF version of The Art of Assembly Language [ucr.edu]. IMHO, it's pretty good, and weighs in at about 1200 pages -- there's more there than you'll probably ever use. I no longer recall if there's a complete guide to the Intel instruction set in the book, but you can, unsurprisingly, get that from Intel's site.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close