Hacker News new | past | comments | ask | show | jobs | submit login
X86-64 machine level programming [pdf] (2005) (colorado.edu)
101 points by adamnemecek on July 4, 2016 | hide | past | favorite | 21 comments



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...)


> I thought it was by and large dropped in 64-bit 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.


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.


It's not that bad. I usually start small:

- 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.


Kip Irvine's assembly language textbook is pretty good, as I recall:

http://kipirvine.com/asm/

At least one guy in our class used Linux tools to work through the chapters we studied, although the instructions are focused on VS.


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".

[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) ]


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.

Such a shame they didn't address this earlier.


The "x64" instruction set was produced by AMD, not Intel. This is why you frequently see the architecture referred to as "amd64".


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).


That started out fairly nice, but then they used AT&T assembly syntax, which made it worthless.

But opinions aside, it does look like a nice reference and exercise piece.


> 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.


While they are the same, Intel is much easier to read.


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! :-)]


gdb: set disassembly-flavor intel

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...


Yeah, I don't understand why some people cling to it so much.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: