Having taken up x86 assembly coding again after many, many years (last time was on a 486, really), I find 64-bit assembly much easier to get started with compared to 32-bit: Simpler calling convention (on UNIX, at least), no segments, more registers, etc. If anyone is starting out, this is a pretty good time to do so.
> I find 64-bit assembly much easier to get started with compared to 32-bit: Simpler calling convention (on UNIX, at least), no segments, more registers, etc.
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).
Oh, well, then I stand corrected. I thought it was by and large dropped in 64-bit mode? (I remember a lot of segment usage in 32-bit, but I only ever coded in real mode back in the day...)
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.
Learning x86 (Intel) assembly is definitely something I've been interested in, as someone who inexplicably enjoys writing C code. But PDFs like this one are all I can really find, which are a bit daunting and intimidating.
- 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.
https://github.com/0xAX/asm was posted a while back on hn - since then it's grown a bit - I've not kept up entirely, but it does start off pretty basic. It's a nice quick read/work-through before you get "serious".
That's rather surpising, coming from someone proficient in C. Perhaps you only need to discover the close connection between C and assembly.
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.
For learning purposes I would recommend against using any kind of macro assembler. As tempting as macros are for making subroutines, calling conventions easier it starts to look a lot like verbose pseudo-C and you're better off just writing C at that point.
Man. First with x64 assembly did Intel catch up with where Motorola was over 2 decades ago with their 68k series.
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.
This 2005 PDF is supplemental material for an old edition of "Computer Systems: A Programmer's Perspective” by Randal E. Bryant and David R. O'Hallaron. The 2015 edition of the book includes an updated version of this x86-64 content in Chapter 3, replacing the IA32 content and no longer a just a supplement. I strongly recommend owning a copy of this book if you have any interest in systems programming or just want to be exploit hardware characteristics for better performance in your userspace applications.
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).
> they used AT&T assembly syntax, which made it worthless
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.
Oy. With respect, you're both wrong. AT&T's is uglier, regardless of the equivalence, and this matters for the cognitive load. But it's not so bad that anyone who uses it should be dismissed.
this is an older version -- the actual book this is excerpted from uses Intel mostly now (the canonical CSPP book) and also has many revisions to 'modernize' it, such as reducing the x86 sections in favor of x64
Having multiple syntaxes and having to switch between them is error-prone and leads to bugs.
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! :-)]
