
If you like allocating memory dynamically. Unix-style system calls you'll need include (but are most assuredly not limited to!) And, unfortunately, system calls are totally and completely different on every OS.

You can write a complete and useful assembly program that never calls external C functions, but if you want to write a pure assembly language program that doesn't outsource the Fun Stuff to someone else's code, you are going to The other thing your program will do is make system calls. Calling C from assembly lets you use things like the C standard library output functions, whileįrom C is typically how you access an assembly implementation of a single performance-critical function. The latter tends to be a bit easier but there's not a big difference. The calling convention works in two directions: you can call C from assembly or assembly from C. Static linking works fine for typical uses of assembly language (like rewriting core functions of an inner loop or other hotspot). In his answer, Norman Ramsey mentions PIC and dynamic libraries in my experience you usually do not have to bother with those if you do not want to. Agner Fog maintains several good resources on his site the detailed description of calling conventions is particularly useful. They're what are most commonly supported, and what you're probably going to be interfacing with if you're The most important part of the ABI is whatever the calling convention is for C-style functions. This part is generally not portable between OSes unless you use trampolines/thunks (basically another layer of abstraction that has to be rewritten for every OS you intend to support).

Userspace is trickiest: you have to get the ABI right or your assembly program is all but useless. The trouble with assembly language comes when you interact with the outside world: the OS kernel, and other userspace code. Unless you're doing extremely low-level hackery (that is, OS development), the nuts and bolts of how the OS and CPU interact are almost totally irrelevant.

AT&T syntax is just one giant headache.) Yes, finding the right flags to pass to the assembler and linker can be tricky, but you'll know when you've got it and you only have to do it once per OS (if you remember to write it down somewhere!).Īssembly instructions themselves, of course, are completely OS-agnostic.

All the official processor documentation does. (Protip: you really want to use Intel syntax. Is a complete non-issue any decent tool will work with both syntaxes or have a counterpart or replacement that does. The other answers currently visible are all correct, but, in my opinion, miss the point. Language, for IA-32 and AMD64 processors and
