Say hello to x86_64 assembly, part 4

http://0xax.blogspot.com/2014/11/say-hello-to-x64-assembly-part-4.html

by nkurz • 12 years ago

120 33 12 years ago

0xax.blogspot.com

_RPM• 12 years ago

At my University, I really wished our assembly class was taught in x86_64. Unfortunately, we learn IBM System/360.

I'm not well versed enough in Assembly to know if learning one "flavor" of assembly would help me learn another "flavor" faster.

But I do know that I use a x86_64 machine myself. Perhaps, Knowing how to write assembly for that instruction seems like it would be more useful.

nightcracker• 12 years ago

The important things you should learn in your computer architecture class is how assembly and other low-level details work in a pipelined register machine. The exact architecture doesn't really matter as the knowledge is easily transferable.

wglb• 12 years ago

I think it will. In any case, it is good to know at least two. I don't mean master, necessarily, but will give you broader perspective on how stuff works.

acqq2• 12 years ago

The dump doesn't have to be AT&T syntax:

    objdump -M intel -d program_name

timtadh2• 12 years ago

Does anyone, (the author?), know the best reference for x86-64 assembly? I have been a loath to teach it to students because there I haven't found great material for it. I use "Programming from the Ground Up"* as my main text for 32 x86 but haven't found anything comparable for 64 bit. I also use:

* http://download.savannah.gnu.org/releases/pgubook/Programmin...

http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in...

Sun Microsystem Assembler Reference http://docs.oracle.com/cd/E19455-01/806-3773/index.html (not because we use that assembler, we use gas for gcc compat, but it very clearly describes all of the usual 32 bit opcodes)

The Intel manuals http://www.intel.com/content/www/us/en/processors/architectu...

Another Intel manual http://www.intel.com/content/dam/www/public/us/en/documents/...

EDIT: I agree with everyone one, I also learned via doing, decompiling small C programs, gdb, and manuals. However, I am looking for something a bit gentler. That process will work for the top 10% but the rest will struggle and at the end of the day they need to write an x86 code generator so without knowing how to write assembly they are in trouble.

stephencanon2• 12 years ago

I learned x86_64 by (a) reading assembly other people wrote, (b) disassembling compiled code, (c) the Intel architecture manuals, and (d) writing a ton of assembly and fixing my mistakes. This is something of the sink-or-swim approach, but I find it works really well; at the end of the day, assembly is really, really simple--the key thing is to just start writing it.

Of course, it's hard to do this sort of immersion in a course where some of the students aren't really interested and just want to know what they need to complete the assignments, so the efficacy depends a lot on the nature of the class.

Cyph0n• 12 years ago

May I ask why one would learn x86-64 assembly other than for extreme use cases like compiler design and reverse engineering? Modern languages and their compilers can usually produce the best possible machine code most of the time. Further, embedded systems run on ARM nowadays which is a bit simpler to deal with due to the smaller instruction set.

mattgodbolt• 12 years ago

If you're using the compiler as a learning tool (and it's great for that!) may I suggest giving GCC Explorer a go: http://gcc.godbolt.org/

The name is deceptive; many compilers other than GCC are available. The turn around time of seeing how small snippets of code translate to assembly makes it pretty well suited to exploring assembly. Though it's my site, so usual author disclaimer here too!

Also I find compiling small tests and then single stepping in assembly mode another way to really 'get' what instructions do.

0xAX2• 12 years ago

[author :)] I'm not sure that i can recomend somethig for you, but for things that i use for learning low-level programming are following. 1. Nasm manual 2. Intel manuals 3. gdb 4. Source code written by other peoples, like bootloaders, simple 64 bit operating systems and etc...

a1a• 12 years ago

Not really answering you. But I feel like sharing the method our lecturer had.

We learned MIPS first and then when people had a grasp of the basics we had lectures (along with intel manuals, abi reference, and some minor internal documents) explaining x64, partly in a "compared to mips" perspective. I believe this method served us pretty good and most had no problem picking up on x64.

nova• 12 years ago

There is "Introduction to 64 Bit Intel Assembly Language Programming for Linux", 2nd Ed, by Ray Seyfarth. It's pretty good for beginners with some C experience, I think.

timtadh2• 12 years ago

Thanks I will check that out!

fnordfnordfnord• 12 years ago

Probably not what you're looking for but Randall Hyde has put up a second edition of The Art of Assembly which is available for free download or at no starch. http://webster.cs.ucr.edu

I don't know if he addresses x86_64 much, if at all though.

ANTSANTS• 12 years ago

"Average" programmers had much more practical reason to learn assembly in the days of 16 and 32 bit x86, of DOS, Win32, and software rendered games, than today when the average programmer writes Javascript or some other dynamic language and is several levels removed from the machine code being executed, so I don't think material written about x86-64 will ever be on the level of the stuff written back then. IMO it makes more sense to stick to the high quality 32 bit texts and let students figure out the 64 bit additions on their own if they want to. x86 is conceptually simpler anyway.

drv• 12 years ago

I am befuddled by the idea of saving the return address explicitly (mov rdi, $ + 15) while also using call/ret. Maybe there is something clever going on here, but I don't understand the purpose.

calculateStrLength is not only calculating the string length; it's also pushing the contents of the string onto the stack (and expanding each byte to 8 bytes, because that's the only valid size of push on x64). The stack pointer is no longer pointing to the return address, so the code puts the return address (which was calculated by hand by looking at the dissasembly and counting bytes rather than using a label for some reason, but I digress) back onto the stack and then using RET to pop it right back off and jump to it (PUSH RDI + RET is equivalent to JMP RDI).

Then reverseStr loops over the string length, popping a character off the stack one at a time and writing all eight bytes into the output buffer (running off the end of the reserved buffer for the last 7 characters, incidentally).

I suppose this is an interesting exercise to understand how the stack and call/ret mechanisms work, but it's not the way to write understandable code. Using the stack in this way will almost certainly also break the return address prediction that modern CPUs perform, making the code slower than the straightforward version that doesn't use the stack at all.

phire• 12 years ago

It won't break return address prediction, as long as the call/returns are matched prediction will still work.

Its a symptom of doing really ugly things with the stack

lgeek• 12 years ago

Its a symptom of doing really ugly things with the stack

Yes, that's spaghetti code. In general I strongly recommended to write assembly functions which follow the platform's ABI (I'm a TA for a course using assembly programming). At the very least, function calls and returning values should be consistent and function calls shouldn't have this kind of side effects. In this case

* calculateStrLength effectively leaks stack space because it pushes the input string and doesn't balance the stack before returning - this is why the return value is passed using rdi. At least the return value pushed by call could have been preserved in calculateStrLength itself. It also increments the size counter without resetting it (it's reset to 0 in _start) which is a bit of a weird choice.

* then reverseStr (which is not a function but just a label in _start) pops the string off the stack and copies it to the OUTPUT buffer (but doesn't copy an end of string NULL character - which works because the buffer is in the bss section, but it's not a good practice). The return address pushed by the call to calculateStrLength is left on the stack.

The whole thing is designed pretty weirdly because reversing a string is trivial to do in place (or with just an input and output buffer), there's no need to use the stack.

acqq2• 12 years ago

Yes, the text is definitely not what interested readers should actually try to achieve, even if it motivated them to learn more.

I don't know about Linux 64-bit ABI limitations, but if you want the interoperable code in Win64, you should actually learn to not use push except in prologs, epilogs and leaf functions and even then the trickier part is to maintain the exception info consistent. So some other approaches are better to learn first.

drv, I also agree, it's highly inefficient making memory pressure n times 8 bytes on the new stack instead of simply accessing the bytes as they are, keeping the caches doing their job.

Say hello to x86_64 assembly, part 4

Related Stories