Slashdot Mirror
Trees Fall Prey to AoA
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 submission is much funnier if you read it in the voice of Comic Book Guy
You're not alone. The problem is in resolution. Text printed at less than 150 dpi has a comprehension rate 50-75% less than test at above 150dpi. In general, the books you find in a bookstore are printed at 1200dpi.
My significant other works at a publisher. When she told me about this, it helped explain a lot.
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. 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.
There's nothing a higher language cannot do that assembler can
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.