X86-64 machine level programming [pdf] (2005)
ecee.colorado.edu
ecee.colorado.edu
Segments are used in about the same amount on x86-64 vs. x86-32. Where they are used a lot is in 16 bit mode (real mode).
Indeed: cs, ds, ss and es cannot be used in 64 bit mode (source: https://en.wikipedia.org/w/index.php?title=X86_memory_segmen...), but fs and gs can still be used. On x86 in 32 bit they are never used at least in ring 3. So not much difference.
fs and gs may still be used in both x86-32 and -64 and gs is for both: Under Windows for accessing the Thread Environment Block and under Linux for accessing per-CPU data.
- Write a program that just returns, or halts;
- Write a program that prints something or blinks an LED;
- Print numbers 1-10;
- Handle some input, using function calls.
- Write some data structure (binary tree or hash table). Or maybe get an MMU working, and handle a system trap.
... working your way up to writing a context switch handler, for a coroutine or threading system, of course :-)
... at that point, you're off to the races. Mostly I try to get the toolchain a debugger working reliably in the first step, and everything just builds on that.
At least one guy in our class used Linux tools to work through the chapters we studied, although the instructions are focused on VS.
[ed: Initial hn discussion should be relevant to this thread: Say hello to x64 Assembly, part 1 (0xax.blogspot.com) https://news.ycombinator.com/item?id=8245581
(The posts are posted on the blogspot blog, but if I'm not mistaken they're all there in full, in the github repo) ]
The layer between them is really razor thin — by learning a few C idioms (function prologue/epilogue and the stack frames, argument passing, etc.) you'd be well on your way. You also need to start writing simple asm code as soon possible; only reading about it won't make it stick.
Lack of registers (and a logical organisation of those) and the boilerplate load/unload pain that caused when trying to write any non-trivial code was why I just stopped doing assembly when I moved to the Intel platform.
Such a shame they didn't address this earlier.
I took the class this book is written for, taught by the authors. They don’t place emphasis on being able to write assembly, since this is not a useful skill for the majority of programmers. Instead, the goal of this material is to get you to understand assembly and compilation well enough to 1) reverse engineer it if you need to for debugging or security reasons, and 2) be able to write compiler-friendly code, meaning code that can be safely translated into efficient assembly instructions (compilers are conservative, they only optimize when it's certain there's no repercussions).
But opinions aside, it does look like a nice reference and exercise piece.
This is so silly. The two assembly syntaxes are equivalent and include just as much information. It doesn't make much to mentally flick between the two.
Except in cases where manufacturers are totally clueless about syntax, I have far preferred using the "official" assembly, rather than the Unix version. (In some happy cases these are the same).
Thank God I don't write assembly language much any more; maybe a few hundred to a thousand lines on a modern embedded product. At that level, it's still fun. [I've been using assembly since the late 1970s. Z-80 and 6502 FTW! :-)]
gcc inline: asm(".intel_syntax noprefix");
objdump: objdump -M intel -d program_name
All the fun of arguments over goddamn bracing conventions in C or C++.
ATT is src,dest
intel is dest,src
Commit that to memory, the rest follows, get on with life which is much too short...