Slashdot Mirror
Assembly Language for Intel-Based Computers, 4th edition
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.
Maybe that's why the book is hard to follow too. I quit at 6502. I gave up after that.
I used this book (3rd ed I think) two years ago in my Organization and Architecture class, and I liked it. The book was an easy, quick read, which is a major deciding factor when you have 3 reading assignments a day. The author uses examples that actually show in code the concepts he's writing about, and the examples are short, to the point, and easy to understand. Assembly language is a rough language when you first pick it up, but I think this book helped me along rather nicely.
~NullPointerException
Can anyone recommend a good book for learning 32bit PPC assember?
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.
Yup, sounds like the utter crap that is the usual fare in the microcomputer world. Piss poor processors, operating systems, applications and manuals. And to think this junk replaced mainframes.
http://half.ebay.com/search/search.jsp?nthTime=2&p roduct=books&query=Assembly+Language
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"
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.
thank God the internet isn't a human right.
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!
What you describe is not "a love-hate relationship." It is a set consisting of love relationships and hate relationships. "Love-hate relationship" means you despise the thing in general but it has some killer feature that you can't live without, or you like the general idea but there is some fundamental flaw. Or that you love to hate it or hate to love it. The only thing worse than using cliches is mis-using them.
Pathetic linux troll.
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
I don't need no instructions to know how to rock!!!!
Here's an excellent free reference - worldly reputation as one of the best from what I hear.
I checked out The Z80 Cookbook by Barden back in 1978.
It will be 24 years overdue in October.
Think they have missed it by now?
I like assembly, it's fast!
IA-64 isn't supposed to be a language useable by mortal men.
It would have been nice to see some x86-64 in there though.
I would lie to you if I told you that I've read the whole book.
Hmm...
the x86 command set doesn't magically change just because you installed linux. There's no such thing as 'OS specific' assembler.
So, int 21 does what on linux? What about int 2e on DOS or Linux?
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:
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!
Blender And Linux Fan
I whould disagree, your trolling.
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.
thank God the internet isn't a human right.
Z80 assembly language was the second language I learned (after BASIC, of course). I'm convinced that learning assembly language was key to making me the (humbly) great programmer I am today.
I've ranted about this before, but I have to say it again: Programming is taught ass-backwards in college. Assembly language should be the FIRST thing taught, and then gradually building up to higher and higher levels of abstraction. All algorithm theory should be taught in assembly. When you've implemented algorithms in assembly, then there's no question that you know them far better than when they're surrounded by 7 layers of syntactical fluff.
Look at the way EE's are taught: You start with the basics of transisters, resisters, capicitors, etc and work your way up. If EEs were taught the same way as programmers, they would start with plugging cards into PCs with component theory being taught as an afterthought!
In my experience, I've often found that EEs converted into programmers are better programmers than people with CS degrees, and I think this is the reason. EEs are taught how to think early on at the component level.
I should also say that it's a total myth that assembly language is "hard". It's not. It's simply "more". More detail, more instructions, more attention to what you're doing. Assembly itself is extremely simple. Get an instruction; execute it; move to next.
Bottom line: TWO years of assembly before a student even sniffs high-level languages.
I keep ranting about this, but I doubt that CS programs are going to change. I can always dream, though.
Sometimes it's best to just let stupid people be stupid.
"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"
Err.. who mentioned Linux? I appreciate that x86 assembler is the same all over, but that is what I am looking for, a *general* introduction. Perhaps my question was badly phrased, but is this book a general introduction to x86 assembly or an introduction to x86 assembly on an MS platform? I don't know anything in any detail about the DOS / Win32 platform, and I don't want that hampering my reading of the book, that's all. Would this be the case?
Try NetBSD... safe,straightforward,useful.
in [very] general ASM is easy and fairly portable accross systems (even though the menomics might change).Now system programming is a different srort it's harder and not portable, unless you plan on kernel hacking your never going to need to know and system specific ASM and you'll need to learn how to use the libraies provided by the OS you are using.
Those were software interrupts used to access the umbrella interrupts of DOS/BIOS. AFAIK, Linux does not use the BIOS interrupts.
"History doesn't repeat itself, but it does rhyme." Mark Twain
Interrupts do whatever their defined it to do. It has nothing to do with x86 assembly, its a subroutine. An assembly text would teach how to trigger/call an interrupt, not what it does, which is OS/BIOS specific. To reiterate; the interrupt mechanism is hardware specific, what the interrupts do is platform specific.
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.
I don't need no instructions to know how to rock!!!!
Well now you've given up assembler you will NOT be able to STA with me. We'd have had a ROR that makes you ROL around AND devide by 2 OR more.
thank God the internet isn't a human right.
Another Jon Katz article?
"Eve of Destruction", it's not just for old hippies anymore...
Not everything need be a pulpit for linux (anti-ms) zealots. Indeed, as not every reference to MS is bashing. I simply know very little about the MS platform, and don't want my lack of knowledge to get in the way of my understanding of the book. Now everyone seems to say this won't be the case, so that's just fine...
Try NetBSD... safe,straightforward,useful.
I'll pay $7 for UID 1000000. Let's go make some accounts!
You seem to be well informed on these issues...
Is it true that if I kill a Muslim, I go to heaven?
Writing a small program in assembly language you could concieveably write your own OS. But I believe the book gives you an assembler that runs in DOS. The version I had created executable .com files. We were given this book as a reference but the instructor didn't teach from it. The book does not really get into operating system specifics, just the instruction set for the CPU. Assembly language is very low level and in my opinion, that and algorithms were the most frustrating classes I took in computer science. We started with MIPS on a simulator called XSPIM which ran on linux too, and then moved to x86 using the before mentioned assembler. I had a very difficult time with it but I managed to get a through it.
Not BIOS interrupts, but (i believe) int 80h is used to switch to kernel-mode for processing syscalls. Also, I'd say that was...important. The startup code (boot.S, setup.S) uses BIOS calls to read the kernel from the boot drive, since there's nothing else available at that point.
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).
Funny, I've found that EEs who learn to program turn out the most obfuscated and counter-intuitive crap imaginable. They're so busy thinking about the low-level efficiency tricks that they forget to make a clean high-level structure, and end up with a total mess. Then they wonder why it's so hard to debug.
There's no question? Bullshit. You don't learn algorithms by delving into inconsequential trivialities. You learn algorithms by looking at them abstractly. Ditto for data structures.
Assembly language should not be the first language taught. The first language should be a middle-level language such as Pascal. (It was designed as a teaching language, and at that it is very good.) After the students learn to think properly, analyze, and abstract, then the curriculum should branch and start moving simultaneously to higher-level languages like Java and lower-level languages like assembly. To start them out at the bottom will unnecessarily complicate their view of computers and programming and leave them unprepared to deal with the truly complex high-level problems like distributed concurrent systems.
alright, alright, whats all this then...we'll have no trolling here. this is a linux site, for linux people - we dont want any strangers here.
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 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.
- INT calls are by defintion BIOS / OS specific. No assembly book that claims to be OS agnostic would use them.
- What fucking crackhead came up with the idea of using hardware interrupts to implement BIOS calls?!!! (Oh, that's right, those fucking x86 crackheads!)
x86 is why I gave up bothering with assembly. It's just such a fucking nasty monstrosity. It's not fit work for humans, leave it to the compilers. (And a few twisted programmers that can relate to that byzantine cruft.)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 remember trying to implement Quicksort in assembly before I really understood what the algorithm was doing. When I finished, I knew less about how it worked than when I started. What a waste of time.
Different algorithms map better to different tools. Some things match well with high level languages. Some things match well with assembly. Some things match well with DNA computing. And I'm sure sume algoritms will seem trivial when implemented using quantum computing.
I do agree with the original poster's point that starting out by learing assembly, and using it to implement appropriate algorithms seems like a good educational approach. Once a student understands the building blocks, they can start studing more abstract tools for solving more complex problems.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Well 65816, but near enough :-)
But would you give a blue fuck? What are the relative values of red and blue fucks? What about other colors, is there a mapping from all RGB triples to the values of fucks of that color?
Indeed!
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.
A message from the system administrator: 'I've upped my priority. Now up yours.'
Try looking at the 68K instruction set, or the Z8000 (or Z80000) instruction set. Nice orthogonal instruction sets, no special purpose registers (except for the stack pointer - A7 and R15/RR14 respectively).
Even better, look at the ARM instruction set. Every instruction can be conditionally executed based on the same flags that other archs (6502, 68000, ppc, x86, etc) use for branches. Heck, even the program counter is a general purpose register. If you want to learn on a simple ARM machine, start here.
Will I retire or break 10K?
Your reward will be here on Earth. The knowledge that your small contribution has helped shape the world into a better place.
Islamics are an invasion force. First they come as friends, then they corrupt the country from within. Like a cancer, we must cut this filth out.
The struggle shall be long and hard, but we will prevail once we realise that yes, we ARE at war. The war of civilisations.
Are you prepared to kill to defend your way of life from the invader?
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.
thank God the internet isn't a human right.
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.
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.
--JoeProgram Intellivision!
I think Irvine's text was a good middle-of-the-road read. Duntemann's "Assembly Step By Step" was very informative and helped me learn some more varied aspects of assembly which Irvine's text was a bit short-sighted with...but otherwise, for a college textbook, it's head and shoulders above many others I've read. Uffenbeck, anyone?
The first time I took Microprocessors, my instructor actually recommended that we use Uffenbeck's text to learn x86 ASM. Thankfully, when I retook the course, we had Irvine's text to accompany it. Don't get me wrong...Uffenbeck's book is good for comparative architecture analysis and the hardware side of things, but it's useless for learning ASM programming.
"Mod, mod, mod...and another troll bites the dust."
http://www.drpaulcarter.com/pcasm/
Check it out. It's got some GREAT information for people experienced with C and C++ who want to learn x86 ASM and how to interface ASM with a higher level language. It's VERY clear and as comprehensive as many are likely to need. Download the PDF and have fun!
The book was well done with lots of examples, but I didn't quite catch on. Not by fault of the teaching materials, but for the topic. I personally found Intel Assembly pretty confusing.
I corroborated this by taking another class next term, which was based on Motorola 68HC11A8 Assembly, and it was a lot easier to understand.
Just a quick peek into X college student's mind...
DOS was nothing more than a shell
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.
Be wary of any facts that confirm your opinion.
As an example,
A matrix inversion routine in delphi took 40mins to do a 1000x1000 matrix inversion, after converting the code to assembler it took 40 seconds(PII 450) which could have been reduced further by rotating some of the data structures to avoid a hell of a lot of cache misses and page faults.
Just define some blackbox functions that you use throughout your text.
Possibly have appendices that describe how one would implement you utility functions for different OSes. If you do, and only provide one example, then you're a lame-o.
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).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Not a flame: What do the salaries look like for programming in low-level languages & situations [assembler, machine code, firmware, hardware drivers, etc.] -vs- intermediate code [C, C++] -vs- high level code [java, SQL]? My impression is that there are so few programmers that write, for instance, good WIN32 drivers, that they can charge top dollar for their services.
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
Using one of my favorite shopping bots to price this book,
i sb n=0130910139
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?
The book comes with Microsoft ASM and thus all examples assume using MASM for their compilation needs. In my class, however, NASM has always been the compiler of choice,
I would lie to you if I told you that I've read the whole book.
It would also seem you would be lying if you said you made it to Chapter 1 -- Basic Concepts, deep into the text on page 3 where it says:
" What is an assembler? "
Hint: Not a compiler.
Linux asm is IMO nicer to work in than DOS asm; partly because everything goes through well-documented int 80h calls, instead of a mishmash of DOS and BIOS calls. And as an added bonus, it's not difficult to call libc functions from Linux asm, whereas Irvine's book only includes his own little library. Other than that, a straight forward Linux asm program looks pretty much like the equivilent DOS asm program.
The ocean parts and the meteors come down
Laid out in amber, baby.
There is a project at http://linuxassembly.org/asmutils.html 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.
HTML is a markup language, not a programming language. Markup languages embed metainformation within the data. Programming languages are instructions, specifying certain execution paths.
No one ever confuses CPUs with hard drives. Why do they persist in confusing markup languages with programming languages?
Good online textbooks for intel assembly are:
w .azillionmonkeys.com/qed/asm.html
"The Art of Assembly" by Randal Hyde
at http://webster.cs.ucr.edu/
(linux stuff as well)
-good amount of detail, only downside is that he uses a language he's developed himself (High Level Assembler) for the code (although HLA does make it easy to learn assembler as a first language)
Dr Paul Carter's book at
http://www.drpaulcarter.com/pcasm/
for more traditional approach of assembler using NASM.
Michael Abrash's "Black Book of Graphics Programming" is also good for assembler, you can get an online copy at Dr Dobbs Journal
A couple of sites for Linux Assembly are
www.linuxassembly.org
www.int80h.org
and win32 at
http://spiff.tripnet.se/~iczelion/
http://ww
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
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
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.
I don't remember how memory allocation works under DOS/BIOS; writing data to disk was indeed done using the BIOS, same with TSR applications and console string handling.
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.
I don't see why anyone would want to read this book. From what I can gather, it teaches 16-bit real mode assembly, and DOS specific programming. These two things are completely obsolete and should not be paid attention by anyone. I'm amazed that people still find value in these two topics. Intel itself has stated that 16-bit real mode should _only_ be used to transition to 32-bit mode. It is merely a holdover from a more primitive system architecture, when people were just starting to make the transition to native protected mode on the PC architecture.
In my opinion, the only worthwhile texts on assembly that might be necessary are the Intel Developer's manuals, which detail most everything an OS or compiler developer would need to know - those two categories of programmer who still need to learn assembly.
I don't remember how memory allocation works under DOS/BIOS; writing data to disk was indeed done using the BIOS, same with TSR applications and console string handling.
.WAD files in Doom), but none of them told the BIOS to read/write at specific sectors on the hard disk.
Yeah, writing data to disk was done using BIOS calls. But DOS told the BIOS *where* to write the data, and that's what was really important. No BIOS understands FAT, AFAIK. Memory allocation was done by DOS, unless you used a protected-mode extender like DOS4GW or pmode.
Saying that DOS was nothing but an interface into BIOS calls is an overly simplistic way of looking at what it did. And I know of no games (at least, ones that didn't have to run on a floppy), that handled their own file I/O. Maybe at a higher level (like
Not that any of this has anything to do with the textbook in question... But I don't think that going into OS-specific details is necessary for an assembly text. It's outside the scope of the book.
--Jeremy
Jesus was a liberal
If you like assembly, and think small, fast code is cool, check out V2OS (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.
There is no reasonable defense against an idiot with an agenda
:wq
i have the third edition at my desk. i found it useful in college to learn assembly, and i find it useful today because it makes the other people with intro java and mcse books think i'm really smart!
Erm, int 21h (used for file access, tsr, and memory allocation) is *not* a bios call. (try an int 21h call in the bootsector, it's just an iret if I recall correctly). Int 13h (disk access) *is* a BIOS call, but doesn't let you write a file, only directly to disk, which will fsck up your file system (pun intended) if you're not REALLY careful.
About those games: those were basically OS-less games. The only thing they used the bios for was to switch video mode, read data from disk (with some custom filesystem) and get input.
It was a completely "userspace" application.
If that's what you call userspace, then LiLo is a userspace application too. <FALLACY TYPE="APPEAL TO AUTHORITY">Believe me, I've debugged more than enough bios and dos interrupts to know what I'm talking about.</FALLACY>
Be wary of any facts that confirm your opinion.
Gentlemen,
Computing is a fast-paced field. What was cutting edge yesterday is as outdated as a pet rock today. Newer, more efficient technologies are always being developed. The 8" floppy gave way to the 3.5" floppy which was later replaced by the CD-R. The acoustic modem eventually yielded to the DSL/Cable modem. Unix was overtaken by Windows XP. And so on.
The same technology also applies to programming languages. C yielded to C++ which gave way to C#. However, the time has come for a complete paradigm shift in programming. I propose a de facto migration towards a relatively new, but promising language known as assembly.
Most of you are probably unfamiliar with this langauge. I know I was until I chanced upon it in my community college while completing my MCSE. So allow me to give you a little background on this language:
C++ and Java do not allow the programmer to directly access the hardware. Instead they compile into a "bytecode" which is then interpretted by a virtual machine. While very portable, this limits the speed of Java and C++ programs.
Assembly, however, was designed to allow the programmer *direct access* to the hardware! This makes for *much* faster programs.
Furthermore, assembly is the same language "spoken" by computers.
Because of this, you may sometimes see assembly referred to as "machine code".
I fear that without the support of a large corporation (the way MS has pushed Java, or Sun supported C#) assembly will fall by the wayside like many other interesting languages (Python, I'm looking at you!) Thus I hope to start a "grass-roots" movement to support assembly. I would like to see the FSF release a GNU-based assembly compiler (although they can keep the bugs that have plagued the 3.0 release of gcc which caused people to switch to Visual Studio for their Linux programming.)
I would love to expound on the superiority of assembly over C++/Java but I'm late for my "Intro to TCP/IP" class. Those of you familiar with assembly, please feel free to educate the many ignorant C/C++/Java users on the glory of this superior language.
Thank you and God bless!
When i had class :).
systems engineering
we learned motorola's Z80, and used no book.
on microprocessors' class we did HC11, with just copies of the instruction sets.
And I learned bits of intel's on a programming lesson where we interfaced the mouse. (DOS)
The library is plenty (well, not exactly plenty, but has at least 4 different assembly programming titles) of books. And I had the documentation for the HC11 downloaded from motorola's site.
So I see no reason why you wouldnt go to intel's site and search manuals and instruction set there. (In fact, just a few weeks ago i got the 3 IA32 Software Developers Manual mailed, for free time reading. Not that I think I will ever memoryze everything, but they are there.)
Besides, its bleeding edge up to date
Back in 95 I wrote a 3D panel-drawing program, but the Binary Spatial Partition code was in C, and on a 25MHz 486 was just too slow. So I decided to write my own practice OS. Well, I didn't get that far, but I *did* make a neat little 4-k program called "Machine Shop". Machine Shop rode on top of DOS (really only needed BIOS), and would handle virtual memory functions, but also made it easy to make modular algorithms and modular data sets, swapping them to the hard disk in an intelligent fashion as memory was needed. One neat thing was that it used IRET to call in both directions. That is, if you wanted to call a Machine Shop function, you set your variables and used IRET. When Machine Shop wanted to call the app, it set its variables and gave an IRET. It worked fine, but was nonconventional. It was just a way to make sure that the same call was always used, and was easy to identify. One other characteristic was that each module also came with its own documentation (input, output, data specs, algorithm, and what it does). Once you get the modular down, then spec changes really aren't a problem. --> Oh... and DOS Debug was awesome. I didn't have the money for MASM, so I did my ASM programming with DOS Debug. When I decided I wanted a few variables, I just wrote a substitution algorithm, and combined that with .BAT files to make my own microassembler. It worked nicely, but took a few minutes.
Correct Horse Battery Staple: 72 bits of entropy. Enter "Correct H" into google. When it generates the phrase, that's
I always was taught that lower memory holds the interrupt vector, and when int 21h is called it took the pointer from 21h and executed the interrupt handling code that 21h pointed to?
I want my rights back. I was actually using them when our government stole them after 9/11.
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!
Don't Tread on OpenSource
i'm going straight to the bookstore! everybody better MOV outta my way!
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
The $ ending a string idea dates from at least CP/M. When you passed a string to print to BDOS (Basic Disk Output System), you terminated it with a special character (set with another system call), traditionally $.
Sigh, CP/M - no directories, but you did have passwords on files!
I would like a book that is targetted at people like me. I would like to be able to fine tune a blitter in x86 assembler. One thing I do not in a book is something that is trying to teach me assembler programming in general. Does this book fall into that category? If not, can anyone name a book out they might recommend to me?
My all time favorite book about assembly "The Art of Assembly Language Programming" by Randall Hyde. It is available at http://webster.cs.ucr.edu/AoA.html.
I have used the third edition of Assembly Language for Intel-Based Computers and disliked it because it was very microsoft centric.
The Art of Assembly has information about Linux, as well as Microsoft centric assembly programming. The are also some interesting teching techniques used in The Art of Assembly which I found work very well.
I'm just gonna stick my neck out and say: Java rocks.
Assembly might be fast etc. but it simply to dated and machine specific to be useful.
One thing that surprises me with open-source is the fact that there is very little support in the community for java. This is after all the language that could make Windows apps work on Linux without any extra work.
And to be honest what's best: spending an extra 200$ on a faster computer (to make up for the slowness in java) and being able to run Photoshop etc, or sitting around with a dopey P200 and running those cute-but-fast Linux programs.
- Waiting for Xandros
Open source is the art of letting other people write your bad code.
Another fuckwad who things he knows everything.
Of course that's true. You're taking a small well-understood problem and you're optimizing past the constraints of the higher-level language. However, that is not where compilers excel. Compilers are good at examining large amounts of complicated data and producing good results. In other words, a compiler is good when you have fifty source files containing eight hundred functions passing around complicated data structures between each other. Sure, you could write that in assembly. But the compiler will beat you every time without resorting to optimization tricks that break the strict correctness checks. It can do register allocation across the board and function inlining recursively and data alignment to aid in cache hits and many other things you cannot because your mind cannot encompass it all. Claiming that you can do better on a small domain of the problem is a misleading anecdote.
Real assembler coders read the uP datasheets and just grok it. Instant karma. Maybe it's a generational thing, but once upon a time there were no textbooks. (Gasp!) There's nothing wrong with using a book if it's there. (In fact you're a lunkhead if you don't make use of all the tools you've got!) And God bless the people who try to write good books. And pay the people who actually do write good docs. But if you need a book, maybe you should consider another endeavour. Suck it up. Be a Mensch.
If you want you can code directly in PASM (Parrot Assembler) or help write some of the tools that parse real languages and emit PASM. It's not a particularly small assembler like 6502 (but it can be if you really want!) but still has that small-system feel.
I got my Assembler fix this past spring with Parrot BASIC (link is PDF).
Get off my lawn.
...but not for x86? Is there a good book to bone up on the details of the x86 that doesn't start with "this is a 0, this is a 1"?
I've done extensive assembly language programming for Z-80, and small to moderate amounts for 68000, PDP-10, PDP-11, VAX, and Alpha, but managed to avoid the x86 until I took my current job. Here most of what I do is well above the assembly level, but it would occasionally help to be fluent in x86 assembler.
I suppose the answer is to just read over code with the Intel manuals in hand to look things up, until I get to where I don't have to look up so much anymore. But I was hoping for something less tedious.
you can kick dos straight into pmode and really play around with the processor(task-switching, calling 16bit dos/bios interupts) without having to worry about a kernel.
thank God the internet isn't a human right.
You can also look at MenuetOS for an example of an ASM OS. It's a complete OS with GUI that fits on a 1.44" floppy. It is very nice to see.
--
If I actually could spell I'd have spelled it right in the first place.
The Turing machine should be taught first
(It was in my Uni days) in conjunction with Von Neumann architecture.
thenassembler, followed by high level languages like C.
End user scripting tools like basic should be left to the arts students.
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 ?
look at this program, a 3d raytraced tube, written in assembly in 32 bytes here.
I took an assembly course for my computer science degree and all I can say WOW! By the end of the semester I felt like just laying down on the floor and just twitching.... twitching..... twitching..... twitching..... twitching..... twitching..... twitching..... twitching.....
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
Back in the late '70s, we had 8 bit microcomputers (Z80, 8085, 6502 (risc without the registers), 6800, 6809 (ah, the 6809... Now THERE was a nice 8bit CPU!)) All these machines were pretty similar. 16 bit address spaces and 8 bit registers (sometimes combinable into 16 bit registers for some operations)
One of the more popular CPUs was the Intel 8080. Zillog cloned (and improved on it) with the Z80 and Intel's answer to that was the 8085. Those 3 CPUs were used for the CPM operating system.
The 6502 was the other popular chip (family)-- used in the Apple II, and Comodore 64 families (among others).
Motorola's 6800 series were a bit less common, but the 6809 was used in the Radio Shack Color Computer. The 6809 was pretty late in the 8-bit CPU era, and was (IMHO) one of the nicest 8-bit CPUs out there.. It had hardware multiply (8x8 ->16 bits) 2 index registers, and a nice, clean instruction set.. and it allowed easy coding of completely relocatable code with 16 and 8 bit relative address references -- including jumps. (but I digress).
When it came time to create a 16bit computer, the different manufacturers went different ways. Motorola, Zillog and National Semiconductors all decided to essentially redesign their CPUs from scratch.
My experience was with the Motorola 68000. It was pretty much a cross between the PDP-11 and the IBM/370 processors. It had 16 32-bit registers split between 8 General Purpose registers and 8 address registers (one of which was the stack). Although the original 68000 'only' had a 16Meg address space, it was only because they only brought out 24 of the 32 available address bits (although there was a version of the 68000 with all 32 bits available). All in all, a reasonably nice processor to program for. It was a 16 bit processor with one foot firmly planted in the 32 bit world.
Intel, on the other hand, decided to build a machine that was backwards compatible with the 8085. The 8086 had a base 16 bit address space with a bunch of 16 bit index registers that shifted the 64K address space in increments of 16 bytes. It also had two (relatively) general-purpose address registers a stack and the program counter. It was source code compatible with the old 8085 instruction set (all you had to do was set all the index registers the same, and you had a pretty good rendition of an old 8-bit processor. It was a 16 bit processor with one foot firmly planted in the 8 bit world.
In truth, what the 8086 did was it formalized the kludgy practice of 'bank switching' which was used by 8-bit hardware designers to get beyond the 64K RAM limit. The Index registers made address math into almost a crap-shoot, because there were 4096 ways to address any given byte (combinations of index registers and 16 bit offsets), and you had to decide between address spacees -- small (all index registers the same) was the easiest, but limited you to 64K for each of code, data and stack). Medium allowed you more space, but nothing could be larger than 64K. Large gave you the full 1Megabyte address space -- and 'unlimited' object sizes within that constraint, but you then had to deal with the horrid addressing scheme. Everytime you accessed any data, you'd have to separately load/calculate the index and address data).
So why would such a horridly designed CPU take over the world?? As one friend of mine used to say "It had 3 things going for it .. I B and M.
As a market driven company (much like Microsoft is now), IBM saw the microcomputer revolution coming, and wanted control of it -- but it had a problem.. Most of the new 16 bit processors were 32 bit machines in waiting -- With 32 bit address spaces, lots of 32-bit registers and the ability to do 32 bit math. Their basic designs weren't that far from the power and ease of IBMs multi-million dollar system/370 CPUs. As such, they were a pretty clear threat to their bread-and-butter mainframe market.
One exception to this was the Intel 8086. With an intrinsic 1Meg address space (Who'd ever need more than 640K anyways?), a couple of 16 bit registers and a hard time dealing with structures larger than 64K, the 8086 -- while able to claim the '16-bit' processor name, was such a hobbled design, that it would never be a real threat to IBM's mainframe architectures. Thus the Intel CPU was chosen for the IBM Personal Computer.
Not in spite of the fact that it was a brain-dead processor design -- but because of it.
Intel -- Just short of Intelligent.
OS Software is like love: The best way to make it grow is to give it away.
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 . 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.
Proud member of the Weirdo-American community.
Actually, the Paul book is good if you can ignore his desire to use the m4 macro preprocessor and get down to the real assembly. Also, keep in mind the 3rd edition of the Paul book is still only for SPARC v8 - i.e. SuperSPARC, not the UltraSPARC. As always, the ultimate source is the SPARC whitepaper in either hardback or downloaded from www.sparc.org.