I have to disagree. Asm embedded in gnu C code has its own very weird syntax (with strange extra semantic rules as well). Learning that at the same time as learning to program in asm is a rotten way to learn to program in asm.

If you want to learn the type of asm programming needed for writing an OS or device driver, then gnu C embedded asm is something you need to learn. I still wouldn't suggest learning it as a first look at asm.

Like any old evolved software project, the Linux Kernel has a lot of baggage, so it tends not to be an example of best practice. For gnu embedded asm, it may contain the best source of examples of that written skillfully and correctly. I don't think that implies best practice.

I think the best reason to learn asm is to improve your ability to code and debug C or C++. Toward that purpose, the thing you should learn to code in asm is whole functions called by the C calling convention. Getting an asm level understanding of the extra details of C++ calling beyond what is in common with C calling is also important, but best done only by stepping into C++ functions in asm view in a GUI debugger, not by trying to write C++ member functions in asm. (For learning C calling standard functions, you should both step into compiler generated ones in a debugger and write your own).

I totally agree.

Just my two cents: Another very good reason to learn a bit of asm is that it will give you a sense of how computers really work. It's something that people who exclusively use high level languages, really lack, IMO.

I acknowledge your opinions and, just so you know, am not interested in flames.

Let me just say, then, that in thirty years of programming I have only found it necessary to dive into "pure assembler" a few hundred times. Looking at the assembly code "to know how calling-convention linkages work" is one thing, but writing large amounts of code in assembler is very rare indeed. Modern-day microprocessors frankly are no longer being designed for handwritten programs: instead, companies like Intel work very closely with compiler-writers (and offer their own). I also am frankly of the opinion that the Linux Kernel code isn't the way that it is because of "baggage." Obviously, a major part of its drive is architecture-independence, hence isolation of architecture-specific code and the expression of "architectural concerns" (PTEs and so-forth) in a somewhat abstract way.

In short, my first response to, "which assembler should I learn to use first?" was, as you can see, "why do you feel the need to use any assembler at all?" That being an honest question; that's all. If you want to learn another language, my first choice certainly would not be an assembler. I'm frankly not that curious how the microprocessor works, most of the time, and especially not these days.

My opinion is, learn to write 64-bit AVX/FMA assembly-language in gas/att syntax. I program at all levels, so assembly-language is a "mid-level language" for me (compared to microcode, FPGA and similar techniques, which are definitely lower-level).

It is [very] helpful to know assembly-language, even if you rarely program in assembly-language. Knowing how to program in assembly-language will help you be a better high-level language programmer.

So, why do I suggest 64-bit AVX/FMA (and SIMD in general), and why advise the dorky syntax that is gas/att assembly?

First, programming with 64-bit AVX/FMA instructions can give large speed increases in key/core routines in some programs. It sure does in my 3D game/simulation engine, where my 64-bit SIMD/AVX/FMA level assembly-language speeds double-precision maxtrix multiplies and vertex transformations by 2.5x over maximally optimized C compilation, and 1.5x over 32-bit SIMD/SSE4+.

Note that 64-bit SIMD/AVX/FMA has 16 * 256-bit wide SIMD registers to compute with, while 32-bit SIMD only has 8 * 128-bit SIMD registers. That's 4x more registers to hold in the fastest place possible for computions, and twice as many operations per cycle.

Second, I advise you hold your nose and program with gas/att syntax for the following two practical reasons. You can have certain build tools assemble the same gas/att syntax assembly-language file for both linux and windoze. This is especially easy for 32-bit mode code, and a bit less easy for 64-bit mode code, because macroshaft (as usual) chose to be stupid and invented a completely braindamaged function prolog protocol (with regard to preserved registers especially) for their 64-bit ABI, just to be "different" than linux). As a result we need a few #ifdef statements in 64-bit assembly to pull this off. 32-bit and 64-bit assembly-language files can be built with the usual gnu tools on linux, and with mingw and mingw64 on windoze (and possibly other toolsets too). Oh, the second reason is this. If you ever decide to write assembly-language for a variety of CPUs, the gas/att syntax will be rather similar for all of them, whereas their native assemblers are often very different.

As sundialcvs might say, "that's just my honest opinion, folks". :-)