Introduction to Linux Intel Assembly Language | Hacker News Reader

Introduction to Linux Intel Assembly Language

heather.cs.ucdavis.edu

63 points0x128 comments

I thought, for a moment, that there was a dialect of assembly language in some way related to the kernel.

There sort of is. The kernel is one of the few places where gas is assumed and AT&T syntax prevails. Tutorials for "x86 assembly" in general almost always use the incompatible Intel syntax.

(They both suck, by the way. Just in different ways.)

GAS is verbose but is "strongly typed", in a Willy-Wonka Hungarian-notation sort of a way.

I've never understood why people fight against AT&T/gas syntax when they're using gcc and therefore gas to do C compiling. It just creates extra work to have to switch back and forth between two assembly syntaxes.

It's like using an Intel compiler that's bundled with a ntel syntax assembler and then coding your assembly in using gas. This is just more work.

Why not just use an assembler that uses Intel syntax? Because you like extra percent signs, a different order of operands, etc.? These are small differences.

What do you achieve by using an Intel syntax assembler? A few small sytanctical differences? Some small differences in macro facilities? Assembly language does not have heaps of abstraction. That's the whole point of using it. A machine instruction has only one form. It's a number.

So why do we need multiple assembly language syntaxes?

Maybe some people just like extra work. Let's write a new language just for fun. Let's change some syntax just for fun. Let's fix something that's not broken, just for fun, ignoring all the things have remained broken and unfixed year after year.

> So why do we need multiple assembly language syntaxes?

There are here for historical reasons, I suppose. Nobody wants to have two assembly syntaxes, but now that we have them, everyone wants his syntax of choice to be the only one.

I learned assembly 10 years ago with the Intel syntax (actually, I wasn't even aware that there was another syntax until recently), and I really dislike the AT&T syntax. So what do I do now? Learn another syntax, or just fight against it?

So, there's no way to get rid of one syntax in favor of the other... The perfect solution would be to have a tool to translate automatically from one to the other.

Should be possible, what do you think?

Assembly without macros is pretty much one-to-one with machine code. Depending on your toolchain you could easily write a shell one-liner to assemble and disassemble it into the other syntax.

With macros, it would be completely impractical to do in the general case, considering the disparity between the macro systems of different assemblers (gas with the C preprocessor, nasm, etc. with their own macro systems).

One unfortunate downside to the AT&T syntax is that the Intel reference manuals all use, well, Intel syntax. It's inconvenient to have the Intel reference manuals while working in an AT&T environment, especially for instructions that are quite different (ie: compare Intel vs. AT&T syntax for the LEA instruction). Intel is really the only architecture, at least now, where there's such a large difference in assembly language syntax -- for the same architecture, most platforms typically only differ in minor areas like expressing relocations. In a way AT&T is also quite a departure from other assembly syntaxes too as most have the convention that the destination register is on the left side.

From my experience, Intel is nicer for addressing (e.g. [foo + bar * baz] instead of -foo(bar, baz, qux) is much more meaningful) and (at least nasm's) macros are more powerful as they can do looping and conditionals, which are useful for static generation of things like tables.

Reply on news.ycombinator.com