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?"

Comments

Too many aspect

[e8johan]

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!

cmp Smaller,Faster

[MarkusQ]

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:

1. Find some way to quantify how slow/fast the program is, and where. This might mean using a profiler, but it might not. Slice the data various ways (by high level task, by thread, by low level functions, by data structures accessed, by calling patterns, etc.)
2. Look closely at the places where the largest chunks of objectionable time are being spent. Consider various refactorings, new algorithms, new data structures, etc. Also look at the customers of the routines in question, to see what their real needs are (e.g. is someone sorting a bazillion data items just so they can pluck the smallest/largest from one end of the structure, or are they recomputing a value that seldom changes) and consider other ways to meet these needs.
3. Make some test modifications, and repeat
4. Once you have a good understanding of what the program is doing, and are convinced that it is being done in the most way practical, calculate how long this should be taking. If the actual times are far above your informed estimate, then consider hand coding.

-- MarkusQ