Trees Fall Prey to AoA 30
bluethundr writes "For all of the years that it has been available, the only way to read the classic instructional text known as the Art of Assembly by Randy Hyde, was to read it online or download a PDF'd copy and print it out for your own bad sef. It would seem that No Starch Press stands poised to release a pre-bound (aka BOOK) version of this most highly esteemed volumes on the arcane topic on highly convenient dead tree media. I for one am very glad about this development. While I recognize the value of hypertext for reference, when it comes to learning any complex topic at length dead tree media is the way to go, hands down IMHO! I emailed the company to get a bead on when to expect this development and this was the reply: 'No, you are not misinformed. The scheduled publication date for Art of Assembly is
March, 2003. I will have something posted on the website very soon, perhaps in the
next couple of days. Thanks for the interest!'"
This story is much funnier... (Score:3, Funny)
i've been waiting for this (Score:2)
Re:i've been waiting for this (Score:1, Flamebait)
Daniel
Re:i've been waiting for this (Score:1)
-- Foghorn Leghorn
Re:i've been waiting for this (Score:3, Informative)
My significant other works at a publisher. When she told me about this, it helped explain a lot.
Re:So what is Assembly Language anyway? (Score:1, Flamebait)
While many optimisations can be had with assembler, due to 'hitting the hardware' it causes more problems than it solves.
There's nothing a higher language cannot do that assembler can. The only difference is in levels. And with current hardware speeds, higher level but typically 'slower' languages become 'fast'.
It's curious that in 2003 assembler is still being practiced. I would put this down to a bit of historical interest, than real practical value.
Re:So what is Assembly Language anyway? (Score:1)
ASM can do things HLL can not. (Score:3, Insightful)
As the AoA author would probably say, you are "severely misinformed". Example, an efficient fixed point multiply, say 16.16. For those unfamiliar with x86 assembly we have two 32-bit operands and the x86 cpu kindly generates a 64-bit result. The assembly language programmer can shift this 64-bit result to obtain a properly scaled fixed point result. It takes one extra instruction over a normal multiply. Doing it all in a HLL is troublesome, using 32-bit types imposes severe restrictions on inputs to avoid overflowing 32-bits, using 64-bit types usually results in grossly inefficient code, often library calls for 64-bit operations. Just one example off of the top of my head. There are many others.
Also, the whole notion that compilers can do as well as humans is naive. Currently compilers are only good when you have novice assembly language programmers. Experienced assembly language programmers often get significant improvements of compilers.
None of this should be interpreted to mean that people should use assembly language more often. They should not:
1. Optimizing algorithms and data access is likely to be far more fruitful. Assembly should only be used after these areas are thoroughly exhausted.
2. They would be assembly programmer is probably not experienced enough and will generate poor code.
Re:ASM can do things HLL can not. (Score:1)
I agree with you up to that point, but the example you provided does not demonstrate anything that cannot be done in a HLL. It only demonstrates that some (most even) things can be done faster. But as the "severely misinformed" correctly said, doing something in a few less clock cycles is no longer important enough in most applications to justify it.
Apart from the odd loop that needed tuning, the only places I have had cause to use assembler since moving up to 32 bit processors has been interfacing to hardware in device drivers, and initializing interrupt vectors etc in startup code.
Re:ASM can do things HLL can not. (Score:2)
If you prefer a different example try branch-less calculations, for example branch-less min() and max().
SSE? I'm not sure how well compilers expose SSE registers and instructions so this may be another example.
What? (Score:1)
That's bad even for Slashdot.
Re:What? (Score:1)
Perl Confusion (Score:1)
Re:Perl Confusion (Score:1)
...But it's the Hash of Hashes that'll really kill you :)
Still relevant? (Score:4, Informative)
Now protected mode x86 isn't all that different, but there are significant differences. You never use BIOS or DOS (heh) calls but instead link to C libraries and (maybe) use system calls directly. You never have a chance to use "port" IO unless you're writing a device driver (and even there it's limited with modern devices). If you have a modern OS (anything except win9x), you don't have to deal with segments but have a flat memory model (by default, you can't even define your own segments (LDTs) in some OSes). The only time you really deal with "segmentation" is when you're setting up your GDTs and call gates in the OS boot sequence, and there it's not really the same thing as 16-bit segmented memory model at all.
I read through AoA a couple of years ago. It was a real pain in the ass to actually set up a DOS environment where I could do any work (ended up using VMWare to run DOS, while actually writing all my real code on the Linux side using nasm and vi (hint: make a hard link to a VMWare virtual disk to bypass file locking semantics and you can mount it r/w while it's being used by your DOS session - very dangerous, but very convenient). Even then, I picked up a copy of 386intel.txt to figure out how to set up a protected mode environment and started writing a kernel right away - stayed away from that 16-bit crap as much as possible.
The book would really be more useful if it didn't deal with all that 1989 DOS crap and dealt with some more interesting issues. People who still write x86 assembly write compilers, device drivers, low-level OS bits, and inner loops (especially for games/media players/encoders/etc). None of this happens in 16-bit mode, and things are very different in 16-bit mode compared to protected mode. Most optimizations I can think of that improved code on 386/486 running DOS actually ends up SLOWER on P4s and Athlons running protected mode. Optimizing modern x86 CPUs is a completely different beast.
Some other improvements I'd like to see in this kind of book: cut out all the tables listing IO addresses and DOS/BIOS INT calls. Instead add a bit describing how different environments have different calling semantics for C functions and system calls. Maybe avoid the masm-specific stuff (I don't even think masm is available anymore unless you download the Windows DDKs, and even there, I don't know if it will produce 16-bit code - at one point, some old 16-bit version of masm was available for free on Microsoft ftp, but I doubt it's still there). It's pretty hard to use this book as-is because you have to set up some kind of DOS environment.
But anyway, this book still rocks. It's where I learned x86 assembly which then launched me into the low-level kernel stuff. If you know SPARC, PPC or MIPS, do not assume that x86 is more of the same. You think SPARC register windows are nasty? You ain't seen nothing yet. x86 assembly (especially the low-level stuff in Intel's volume 3 CPU reference, the systems programming stuff) is so immensely nasty that you get an unnatural sadistic joy out of writing some tight code - it's kind of like writing a sendmail.cf from scratch.
Glad to see this in dead-tree form - I might pick up a copy for my library. If it has a nice lay-flat binding, it'll be much more convenient than the PDFs.
If you want to learn this stuff, you'll also need these [intel.com]. The modern ones are kind of verbose since there's so much that's been tacked on to modern x86 CPUs...you may prefer an older version. Try one of these [google.com].
Re:Still relevant? (Score:5, Informative)
You havn't checked back in awhile...AoA is available in the old 16 bit/DOS [ucr.edu] version, as well as an updated 32 bit/Win32 [ucr.edu] and (finally) a 32 bit /Linux [ucr.edu] version!
Re:Still relevant? (Score:2)
Very cool. I'm buying it.
Re:Still relevant? (Score:1, Informative)
The published version of AoA deals with 32-bit flat model programming. Other than as a historical reference, it doesn't even mention real mode.
I decided DOS was dead back in 1996. That's when I began developing the High Level Assembler and the 32-bit edition of AoA. Note that AoA/32 does not teach "linking to a few C routines." As the 16-bit edition did, it uses a "standard library" written specifically for 80x86 assembly language programmers. The concept, however, is the same.
Also note (to some people's dissatisfaction), the 32-bit edition doesn't cover hardware like the 16-bit edition did (i.e., it doesn't list out port addresses or tell you how to program the serial and parallel ports). Modern OSes obviate the need for this (and, as you point out, for the most part prevent such access anyway). AoA is really intended for beginning assembly programmers, not die-hard embedded assembly programmers. In an attempt to save a few trees, much of the hardware stuff was moved to a different book (that will probably be coming out next year).
1. All the tables listing DOS/BIOS interrupts are gone
2. The book uses the High Level Assembler (probably a bit more controversial than using MASM, but it's a far better pedagogical tool that MASM).
3. Some people claim it's hard to set up a Windows or Linux programming environment
I couldn't agree more. That's why the published edition of AoA was specifically written for Windows and Linux
2. There is a chapter on mixed language programming that covers Pascal/Delphi/Kylix, C/C++, and stdcall function invocations.
3. Like the 16-bit edition, AoA/32 does *not* cover writing optimal code in assembly language. You have to learn to walk before you can run! AoA is about bringing people from point zero to the point where they are competent enough to start learning about all the optimization stuff. Keep in mind, AoA was originally written as a college textbook; something to teach students assembly language programming who'd had *one* quarter of C/C++ programming as a prerequisite.
The published version of AoA has been streamlined to help achieve that goal even better. While AoA has generally been recognized as one of the most comprehensive texts on assembly language programming around, even in the PDF forms (1,500 pages!) it's nowhere near big enough to teach everything about assembly language programming. However, once someone finishes AoA, they're in a good position to read the Intel documentation or Abner's optimization guides, etc.
AoA/32 published edition features:
1. Common language for Windows and Linux users
(Portable assembly language! Almost all the example programs in the book compile and run under either Windows or Linux, unchanged!)
2. Much of the arcane hardware information that I've discovered has gotten in the way of learning *programming* has been moved to a different book. AoA has been streamlined to emphasize assembly language *programming* (e.g., discussions of gates, I/O ports, and the like are gone).
3. The book has been reorganized to get people programming much more quickly (e.g., during the first week of an assembly language programming class). The original versions (both 16 and 32 bits) required considerable study before you started writing "real" programs.
4. The published edition (obviously) has been proof-read and cleaned up quite a bit, making it easier to read. Obviously, a lot of mistakes have been corrected, too.
Note that the PDF and HTML versions will continue to be available on-line (as well as appearing on the CD-ROM accompanying the text). So all that extra information that got cut will still continue to be available.
I'm currently in the proof-reading phase of a second book I've entitled "The Things You Need to Know to Write Great Code" that deals with the hardware issues (ne: machine organization) that got cut from AoA. One of the main reasons given for learning assembly language programming today is that it helps HLL programmers understand the underlying machine organization, enabling them to write better HLL code. The purpose of W.G.C. is to teach the machine organization aspect without having to learn all the assembly language stuff.
Alas, W.G.C is quite long and the proof-reading process is going to take a while (AoA had the benefit of over 10 years of student and reader feedback, so proofreading was a whole lot easier than your normal technical book).
Cheers,
Randy Hyde
Re:Still relevant? (Score:2)
I didn't mean to sound harsh - that's just sort of how I usually write. Like I said, AoA rocked, even when it was just 16-bit stuff - it's just that the programming environment (DOS) left something to be desired. My university didn't offer anything in the way of assembly programming (just some architecture courses, and a compiler course that generated SPARC v8, but it had plenty of theoretical CS stuff, so I'm not complaining too much). AoA was how I really got into assembly programming. There's a certain rush you get from programming directly to the machine. I wouldn't be doing the stuff I'm doing now if I hadn't read AoA.
Thanks very much for AoA. I'm looking forward to your next book as well.