|
|
|
How I learned: Step #1: read the arch manual for some CPU. Read most if not all of it. It’s a lot of reading but it’s worth it. My first was PowerPC and my second was x86. By the time I got to arm, I only needed to use the manual as a reference. These days I would start with x86 because the manuals are well written and easily available. And the HW is easily available. Step #2: compile small programs for that arch using GCC, clang, whatever and then dump disassembly and try to understand the correspondence between your code and the instructions.
|
|
 |
|
The Godbolt compiler explorer can be very helpful for step 2 there. It's neat to see how different compilers codegen the same source.
|
|
|
|
Play through the game Turing Complete, by the end you'll have built your own ISA and solved some puzzles with it. Keep playing for to get on the high scores list and you'll turn those assembly routines into ASICs.
|
|
|
|
|
I don't have a good book to suggest, but one tip you may find helpful: A typical function has two kinds of assembly code: (1) The ABI-required logic for functions and function calls, and (2) Everything else, which can be more or less whatever you want. As long as you don't stomp on the details required by the ABI.
|
|
|
|
|
There are two aspects to assembler. One is the target machine - learning what instructions, memory, performance characteristics you're dealing with. The other is the assembler - what syntax it gives you, how it handles macros, whether it optimises, whether it does any semantic analysis. GNU AS is different to NASM is different to flat assembler. I didn't get much out of reading compiler disassembly relative to handwritten assembly. I'd recommend trying to find some of the latter, might need to be maths libs or video codecs or similar. I'd be interested in recommendations here, the asm I learned from was proprietary.
|
|
|
|
For those who want to do x86 assembly first, google Paul Carter assembly language. It could be one option.
|
|
|
|
|
I'd suggest working incrementally from areas of your existing strength. Tweak whatever code base you are most familiar with, starting with a tiny change, and see how the assembly changes. I use objdump -d and git diff --no-index for this all the time.
|
|
|
|
A great way to learn assembler is to closely examine code generated by a compiler, e.g. on godbolt.org.
|
|
|
|
|
Aside from what has already been suggested, you could consider reading selected chapters of Intel's programmer manual. I personally read through the whole thing once (well, skimmed some parts). From my experience, Intel's x86 manual is better and easier to read than AMD's. It's a free download.
|
|
