Slashdot Mirror
Learning x86 for Non-x86 Assembler Programmers?
An anonymous reader asks: "I've done assembler for the 6809, 68000, 8085, MIPS and ARM architectures over the years. But - I've never learned assembler for the most common architecture out there. I would like to change that. I can roughly follow my way around x86 disassemblies, but I'm not as good at optimizing/fine tuning bits of assembler because I am not intimately familiar with all of the addressing modes etc. I would like a book that is targetted at people like me. I would like to be able to fine tune, say 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. Most assembler books seem to fall in the latter category. Are there books out there that might prove useful to me?"
A website that could come in handy for learning about x86 assembly language is DDJ Microprocessor Center. In specific, the On-line Intel Documentation links are almost invaluable when learning to code for the x86 architecture. Being Intel reference manuals, they tend to cut to the case relativly quickly.
How about the book that was reviewed here on Wednesday?
Thats a great suggestion, all the low level documenation is downloadable from Intel's site in PDF format.
You can also request a free CD with everything you'd need on it.
AMD also have documentation up on there site and I think the x86-64 documentation is also available for free on a CD.
thank God the internet isn't a human right.
I would not recommend anyone to optimize modern x86 asm by hand. If you know your way around disassembled code you know enough to find any (rare) compiler mistakes. Any other operation is usually done better by a compiler. (Please don't yell at me with small, hand optimized special cases, compilers do a good job today if your application isn't very special.)
If you would try to hand optimize asm code for a modern cpu you must concider many issues, among them the reordering of instruction in the processor, the different layouts of the pipelines in different processor models (even intels differ to other intels), cache effects (I suppose that you must link everything statically and control where in memory your code will end up)...
You must also unroll loops, change the access patterns to 2D data structures to improve cache performance, avoid inner loop data dependencies, etc. It is simply too much to handle by hand.
As you probably know a higher level language such as C/C++ and don't write a highly optimized operating system (or work without an OS) you do not need, and should not want to, optimize your asm code by hand!
You underestimate the speed gains to be had (up to a factor of 10 in certain cases) by replacing computationally intensive floating point code with SSE or 3DNow! instructions. Assembly Language will always be relevant in these cases. No compiler exists which can exploit SIMD architectures to the full on commodity hardware. http://libsimd.sourceforge.net
Stick Men
Shh! It's a secret, but Intel offers 4 very nice books at a great price: free.
They aren't tutorials, so there isn't the same hand-holding that you would get in a book from Barnes & Noble, but they explain things well enough that a seasoned assembly programmer should be able to follow with no problem at all. I think they are exactly what you want.
Time flies like an arrow. Fruit flies like a banana.
Check out MenuetOS, "a fully 32 bit assembly written, graphical OS for asm programming, distributed under General Public License". My friend joked that it ran faster under VMware than Windows does natively.
I'm surprised no one has mentioned this book already, because it's exactly what you're looking for. The only problem is that it's dated - it considers the 80386 to be a new processor. There was a time when no self-respecting assembly programmer would be caught dead without it. Alas, I sold mine a couple years ago, since I already learned everything I could from it.
The only problem is that it (like all of Abrash's books) has been out of print for a long time, and so it will be very hard to find.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
Most recent printing would be in Graphics programming black book, but that too has lapsed out of print.
Slashdot article a while ago linked to a download of the complete text, ie Slashdot, but doesn't seem to link there anymore, perhaps someone else would have an idea where the find the download.
/* TODO: Spawn child process, interest child in technology, have child write a new sig */
So you've been doing assembly for well-designed modern architectures and now you want to learn it for that bit of kludgery we call "x86"? My advice is to run your brain through a kitchen blender and then pour it back into your head. The x86 architecture may start making sense after that.
Sheesh, evil *and* a jerk. -- Jade
Actually, with a modern compiler like gcc 3.2, this might not be true anymore. For relatively simple programs like "hello world", many modern compilers can optimize compiled code to the point where there is no difference from writing the program from hand in asm. I've tested this myself with earlier gcc3.x versions (actually, even before 3.0 came out).
In this age and time, asm is particularily suited to computationally intensive portions of programs. Yes, it's probably not going to be faster if you write the whole thing in asm, but it'll not only be apt to be bug prone, but the development time will likely take longer.
Didn't think so. :)
Al Qaeda has ninjas!
If you're in Linuxland, you might find linuxassembly.org helpful. I've done some assembly before (only a semester's worth, though), and the site was rather useful to me. If you've never done x86, though, there might not be enough there for you . . .
Al Qaeda has ninjas!
That, is why ASM is better then any HLL. I think the best quote I got from one of my Computer Engineering book was (paraphrasing) "Modern compilers with their optimizations are on the road to becoming almost as good as hand writen assembler."
Now, would I write word processor in ASM? Not bloody likely, HLLs make it much easier to do. But, when you are writing code for some type of embeded system that doesn't have a whopping 2 GHz processor, ASM will beat any HLL hands down. Unfortunately, too many people think ASM is dead, never learn it, write their embedded code in C and when it isn't fast enough, tell their supervisors that it needs a faster processor. Consider this scenario (stolen from one of my profs):
- Coder writes embedded system in C.
- Code isn't fast enough makes company buy faster processor
- Each processor adds $10 to cost of said system.
- $10 * 1e6 units = $10e6
As opposed to this- Coder writes embedded system in C
- Code isn't fast enough
- Company calls in consultant
- Consultant reads C, looks at the ASM it creates and spends one night tightening the ASM up.
- Consultant head off to Florida for the rest of the week
- At the end of the week consultant makes himself looked disheveled and stumbles in saying "It took all week, but here is the code, it will save to $10 per unit"
- Consultant Charges $2e6, which will the company gladly pays, considering it saves them over $8e6.
See, knowing ASM and how processor works is a good thing that can make you money (maybe not as much, but still a nice whopping amount for a few days work). ASM is still needed, and anyone who says different, does not understand how computers work.Objects in the blog are closer then they ap
Every time I see that article I have to point out that it's easy to do much better than that.
./a.out; echo $?
...
...
...
$
42
$ wc -c a.out
7 a.out
$
Can you guess the contents of a.out?
$ cat a.out; echo
exit 42
$
(the "; echo" is there because a.out doesn't have a trailing newline - every byte counts!)
Stuart.
"Of course, half of the values in this file violate some part of the ELF standard, and it's a wonder than Linux will even consent to sneeze on it, much less give it a process ID. This is not the sort of program to which one would normally be willing to confess authorship."
LOL. This guy should edit everyone else's documentation. A good quick quide to the mechanics of getting started with ASM.
Webster -- The Place on the Net to Learn Assembly Language Programming
See The Art of Assembly Language Programming
I don't know why but old-school guys (like my Dad) talk about "writing in assembler."
-Peter
And Smaller == Faster.
Not always. While I have been known to drop into assembly, it should never be the first recourse when you are trying to speed things up. If it is, you are likely to miss out on the biggest savings. My rough priority list:
-- MarkusQ
For the same reason you "code in C" or "code in Pascal" or "code in BASIC". The common use terminology has always (well, for the last 30 years) been to code in the . So you "code in assembler".
Can You Say Linux? I Knew That You Could.
Which kind of defeats the purpose. :)
Al Qaeda has ninjas!
Since its optimization you are concerned with I have a few choices you will be interested in:
1. The Zen of Code Optimization by Michael Abrash.
2. Agner Fog's Assembly Resources
3. The Athlon Optimization Guide
4. Intel's IA32 Optimization Guide
5. The Aggregate Magic Algorithms
These sources will give you everything you need to know about code optimization for x86.
I don't see why you have to worry about that. The article was about minimizing the size of the executable file itself on disk, not in memory (otherwise some of the last few optimizations would be counterproductive: one of them increases the amount of memory requested in order to reuse a particular byte).
;) (besides, I claim I could probably find a combination of kernel and shell which total smaller than the linux kernel, and on which "exit 42" would still work, but his 45-byter is x86-linux specific)
If the size of bash is going to be counted towards my seven-byte program, you'll have to count the size of the kernel towards his 45-byter. Sure, I still lose because bash+kernel+7 is greater than kernel+45, but at least the ratio isn't so bad as bash+7 vs 45
Al Qaeda has ninjas!
Al Qaeda has ninjas!
http://grc.com/smgassembly.htm
Yep, Gibson writes gui Win32 windows apps in pure x86 assembly. He's nuts, but his apps are tiny and run fast. Lots of good resources there.
Shhhh! Don't tell that to these guys:
...or...
Also, from what I understood, the WordPerfect Corporation actually required that all programs be written in assembler. BTW, some more interesing WP history.
Oh, you mean, you wouldn't use assembler to write a word processing suite nowadays. Ok, I getcha. Yeah, I think you're right. After all, WordPerfect Corp has been out of business for how long? (Well technically, bought out and resold, and resold... They're just a name now.)
--JoeProgram Intellivision!
It's from 1994 and thus the pre-MMX, pre-P6 world, and it is not especially well written (although not bad), but there is a good discussion of segmentation and of which instructions pair in the Pentium's different pipelines, and it really walks you though optimizing a bunch of code.
I think some of it might well be useful relative to the ten bucks it's going for on half.com. (Actually, I found it remaindered for $4.00 at the Cambridge, Mass Micro Center, so you may do a little better too.)