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

First, get the reference books

[cookd]

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.

Re:proccessor that runs 2.5GHz in 640MB ram

[Electrum]

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.

For Linux

[cjpez]

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 . . .

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