I took a quick look. If I understood correctly, that book focuses on
32 bit x86
Whole programs in asm
If you want to learn 64 bit asm, some reference (not tutorial) documents you really should have are:
and the newest ABI from
26568 covers SSE2, which is a nice next step after the basics.
For more advanced 64 bit programming you should also find 24593. To find any of these (they move around) I do a google search for AMD and the document number.
Those AMD documents use the operand sequence of Intel syntax. AT&T has the opposite sequence. But it isn't too hard to get used to remembering the document's operand sequence is backward. Armed with that knowledge, it should be easy to look at the asm code from a compiled C function (preferably in a GUI debugger, where you can step through and see register values as they change) and look up the instructions and addressing modes in those PDFs and understand what the code does.
Once you understand how a function compiled from C acts in asm, it is easy to write your own. No tutorial needed.
The ABI document can be confusing because it gives a lot of detail in order to put precision ahead of comprehensibility. There are two simple register lists whose meaning is almost all you ever need to know from the ABI:
passed: rdi, rsi, rdx, rcx, r8, r9
preserved: rbp, rbx, r12, r13, r14, r15
When passing parameters to functions, many parameter types are reasonable to pass in registers. The first six such parameters are passed in the registers listed.
A function is free to modify most registers, so when it returns those registers must be assumed to have lost whatever useful contents they might have had. But if a function uses registers in the preserved list, it must save the value each had before and restore it before returning.
Another important fact in the ABI is that function return values that can reasonably be in a general register are in rax.
For all the cases where you can't easily tell whether a parameter or return value should go in a register, the ABI ought to tell you, but I think it only yields that knowledge to ABI guru's. The easy way to answer all obscure ABI questions is to write a simple C function that has the same ABI issue, compile it, and see what gcc did.