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?
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!
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!!!!
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.
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.
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.
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).
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.
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.
Well 65816, but near enough :-)
Can an assembly book be (completely) OS agnostic?
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;
}
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?
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."
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.
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
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
Well, you could always link against libc and use standard C functions. Dynamic libraries are weird in Linux asm, but you could simply link statically, and it would be mostly (completely?) the same as static linking to libc in dos/windows.
The ocean parts and the meteors come down
Laid out in amber, baby.
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.
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 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.
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!
First of all C/C++ haven't been replaced by C#. Second, C++ is NOT compile into any kind of "bytecode" or run on a virtul machine. Third, you can talk directly to the hardware. Fourth, assembly is not spoken by the hardware, and is not machine code. It is a nmeumonic representation of the machine code. You should get your facts straight.
Anonymous Cowards suck.
Programming languages combine declarative and imperative elements. HTML is declarative, PHP is imperative. I don't see your problem. Actually I'll go one further; I don't think the problem is so much with the world as it is with you... I see it as net positive that HTML coders consider themselves programmers. Perhaps not programming as I learned it, or you did, but still abstraction, expression and execution. I think HTML coders have a refreshingly new perspective on the ideas surrounding programming that those of us too heavily steeped in the tradition of procedural and object oriented languages would have completely missed (and many people still do miss.)
--
BitTorrent in C -- LibBT
http://www.sf.net/projects/libbt
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.
What fucking crackhead came up with the idea of using hardware interrupts to implement BIOS calls?!!! (Oh, that's right, those fucking x86 crackheads!)
How do other architectures handle these? I'm only familiar with x86 assembly myself.
Anyway, who thought 8 hardware interrupts were enough? The cascaded PIC is not the best design possible either. Yet, most modern computers still have this basic design, so it can't be all bad, can it?
Be wary of any facts that confirm your opinion.
Still, you wouldn't know why the compiler is better than you are without understanding the principles behind the eventual assembly language.
Compilers do many tricks, but often times they need help from the programmer to know it's safe to do them. For instance, knowing minimum trip counts, pointer alignment, pointer aliasing information and so on can help a compiler dramatically, especially if such information is not immediately obvious from the code but is necessary to enable a class of optimizations.
Another factor is the type of architecture involved, and the delta you're willing to live with. I estimate that on most compute-intensive loops, GCC for x86 is off from my most-optimal hand code by as much as 50% (meaning, it runs half as fast, or takes twice as long as my code). For nearly anything I write on x86, that's perfectly acceptible and I don't write a single line of x86 assembly. In contrast, in DSP space, where cycle counting is a way of life, our compiler gets to 80% to 90% of hand-code performance on most of those compute-intensive codes, but we still hand-code. Why? Because those inner loops are 80% to 90% of the total run time and it can make the difference between 90 channels and 100, and that translates into $$. (Alternately, it can mean the difference between making a realtime deadline or not, which is even more important.)
Elsewhere, you said: "Claiming that you can do better on a small domain of the problem is a misleading anecdote." I don't think it's particularly misleading. I know better than to spend my time coding large stretches of branchy control code, but I also know that I could easily beat the compiler if I chose to do so. Only, it could take me days or weeks to get something that runs well as compared to minutes with the compiler. And that's why we have the compiler. :-)
Assembly is for the hotspots. You need to understand assembly to understand why the hotspots are hot and what to do to cool them off a bit.
--JoeProgram Intellivision!
Now, now, just because I know everything doesn't mean you have to get snippy. Be assured that I use my powers for good, and not evil.
Sometimes it's best to just let stupid people be stupid.
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.
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.
for (register long l = 0; l < 0xffffffff; l++)
{
}
and got:
nop
For a giant speed increase!
Do you even lift?
These aren't the 'roids you're looking for.
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.
As far as programming credits go, I first started programming in my late teens back in 1978, on various systems including the TRS-80, PDP 1170, and a DEC 10. My first open source development effort was a little assembly language hack for CP/M that loaded a shell overlay (a free but not open source program distributed by DRI IIRC) in about 10 seconds from disk rather than the 40 seconds it took on its own. Back in the days of SunOS I open sourced 'acc', a shell for 'cc' that translated ANSI'isms to K&R, and also 'ctoh', a program that combines non-code generating and code generating code into a single source file, seperating them only at compile time. Commercially I've personally written tens of thousands of lines of C, about 100k lines of C++ (with CORBA), maybe 20k lines of Java. This doesn't begin to cover the number of shell scripts, lines of Perl, or anything else that I've written just to scratch an immediate itch. If you want to see examples of my code, I occasionally manage to add new code to my open sourced Dragon's Reach project, including what I think is a pretty good combination of RPC and XML in the xdrxml subdirectory.
So I don't think I'm trolling... I'm trying to get across something I think is actually quite important. You say HTML isn't code, I say that is because you want there to be a distinction between the elite coders and the non-elite HTML'ers; the means that they have to get a computer to do what they want are quite different from yours, but the things that they have accomplished would have been quite impossible starting from an ORB. The future of distributed programming belongs to loosely coupled systems, and thus to those with the web mindset, and not to you, for the same reason that NFS cannot be run effectively over an area larger than a LAN, while http protocols run everywhere.
--
BitTorrent in C -- LibBT
http://www.sf.net/projects/libbt