Assembly Language for Intel-Based Computers, 4th edition 255
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.
Re:Assembler is hard to follow? (Score:1)
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"?
Re:Assembler is hard to follow? (Score:2)
My votes are for "elephantine", "bletcherous", "monstrosity", and best of all, "bogus".
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.
Re:Assembler is hard to follow? (Score:1)
God I had a hard time remembering those. That's good.
you were lucky (Score:1)
Re:you were lucky (Score:1)
Re:you were lucky (Score:1)
Re:Assembler is hard to follow? (Score:1)
Re:Assembler is hard to follow? (Score:1)
Re:Assembler is hard to follow? (Score:1)
Tell that to the now-defunct WordPerfect Corporation that couldn't make the jump to Windows cleanly because of the mandatory "everything in assembly language for speed and size" coding rules there.
And I say this as a former die-hard WordPerfect 5.1 user.
High-level language has its place, and when coded well, can perform as well as you need it to.
--JoeRe:Assembler is hard to follow? (Score:1)
That's like 3 katrillion lines of ASM
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.
I am programming it today! (Score:1)
Ahh...memories (Score:4, Insightful)
PPC Assembly (Score:1)
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)
Shit, we're using hex numbers on slashdot. Where's that annoying guy [slashdot.org] who always complains about people not using hex on slashdot? This would make him proud!
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/
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?
Re:Academic Pricing sham (Score:2)
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)
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)
Re:Yet another assembly book outdated at release (Score:1)
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.
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, Interesting)
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)
Re:Yet another assembly book outdated at release (Score:2)
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.
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.
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: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:2)
Re:A lost art, alas (Score:1)
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
Re:A lost art, alas (Score:1)
If they want to be anything above mediocre, I believe so.
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.
Re:A lost art, alas (Score:1)
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.
--JoeRe:A lost art, alas (Score:5, Interesting)
strings (Score:1)
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)
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:CPA program (Score:2)
Netscape 7 is ADVERTISING ENRICHED! With new, IMPROVED popup windows!
Re:A lost art, alas (Score:1)
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)
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)
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.
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)
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:2)
asm is hardly tough. Show me subtraction in lambda calculus. Now that's tough.
Re:A lost art, alas (Score:2)
My history of languages learnt are (roughly):
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.
Re:A lost art, alas (Score:2)
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.
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"
Re:Love/Hate relationship (Score:3, Funny)
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.
--JoeRe:To those who think assembly is irrelevant (Score:2)
My answer: Only if you want to write a compiler, or an operating system or do CPU design. Or, if you want to actually understand any of those things. In a group of computer science majors, that usually shuts them up.
Tossing 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.
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.
Books To Learn Assembly? (Score:2, Funny)
No wonder our education system is going down the tubes!
Non MS-DOS/Windows book (Score:2)
Chris
What about a book on AT&T assembly ? (Score:2)
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
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: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:Windows (Score:1)
x86 assembly has no more to do with linux/dos than M68k or Z80 assembly has to do with the Sega Genesis.
By the same token, a good C++ text wouldn't get into the ridiculous details of ioctl.h or windows.h
Not everything need be a pulpit for linux (anti-ms) zealots.
Re:Windows (Score:1)
Re:Windows (Score:1)
Sticking with DOS and then using DPMI for protect mode-32bit programming would have been a good idea, DOS is nice and raw and so doesn't distract from what you are doing.
Using Windows (or Linux) just distracts from the goal of the book, teaching assembler.
I susspect the books is only a best seller bercause it's on the required-reading list for some CS courses.
Re:Windows (Score:1)