ASM syntax standard

[viral]

gcc (inline) - AT&T
nasm - Intel

Why they use AT&T and Intel both...
cant just one standard be their?

[distantvoices]

I dunno, those compiler developers say: let it be like this - and we, the poor swines having to use these compilers have to live with their saying. and as there are sooo many developers fr compilers (and some might consider themselves genies) there grow different standards like hay in the cot.

stay safe

ps: Solar has found the split button. About time, I reckon. *chuckle*

[Solar]

I took the liberty of splitting this into a thread of it's own, as it had little to do with the 2002 relic it was attached to.

[AR]

GCC runs on top of GAS which is an AT&T syntax assembler (GCC generates ASM then runs it through the Binutils Assembler), GAS' native syntax is AT&T, I think the reason for this is that AT&T is more portable (GCC is a multi-platform compiler that can also cross-compile). If you want a universal Assembly language then you'll have to learn GAS, GAS does have an Intel syntax directive though (something like .intel_syntax) but you'll have to remember to switch it back to AT&T mode at the end of every inline or your C/C++ code won't compile.

[Brendan]

Hi,

Why they use AT&T and Intel both...
cant just one standard be their?

IMHO, on Intel CPUs Intel syntax is standard. AT&T syntax uses the same rules for many completely different CPUs, and therefore ignores any CPU specific standards.

Compilers like GCC probably could use Intel syntax, but it's easier to stick with the same syntax rules for all CPUs.

What I want to know is, why are there different standards for English? Surely those pesky Americans could learn to spell things correctly....


Cheers,

Brendan

[Curufir]

Fundamental difference is GAS allows for more than two operands per encoded instruction. Everything else is just semantics.

If you're using C then it's probably best to learn AT&T syntax because it's far easier to inline in GCC (If you use this compiler). Either way you're going to have to port any assembly for each platform you want to support. Nobody's written a portable assembler, mainly because it'd be a compiler ;D.

[Solar]

IMHO, on Intel CPUs Intel syntax is standard.

Intel syntax is what's used in the Intel CPU docs, and the native syntax for various popular assemblers.

There is no such thing as a "standard" ASM syntax for any CPU I know of. The machine code is, obviously, defined and cannot be changed. Everything between machine code and ANSI/ISO C (or some other officially standarized language) is terra incognita, interpreted on each assembler programmer's whim.

That being said, the Intel syntax is - probably because of the low-endianess of the Intel CPU family - considered "strange" by virtually everybody who happens not to have encountered it as the first ASM language. Anyone who learned his / her stuff on a C64, Atari, Amiga, ZX80, whatever, will tell you that "moving a to b" is the right way to say it, and that explicitness of operator types is A Good Thing (tm).

[Pype.Clicker]

hah ! ASM standard ? no way, dude.

That's even worse: among intel-looklike syntaxes, assembler will vary about details like "how to encode hexadecimal numbers" or "how to express segment overrides" or "how do i tell if i want a byte, word or dword stuff ?". That's as old as the "MASM vs TASM" duel and both FASM, NASM or A86 has specifities that makes asm file made for one of them totally useless for other ones.

e.g. you could have

Code: Select all

mov WORD PTR [es:si], 0
mov es:[word si],0

and it get even worse when you try to write macro or directives (include, equ, struc, extrn, and the like)

[bubach]

Tss.. It's not that bad...
Trying to understand AT&T, thats _bad_...

[srg]

I'm finding that pure GAS isn't that difficult, it's still takes me a good day to get a section of AT&T inline assembly to compile without some error.

srg

[mystran]

There probably aren't that many like me, but I learned my assembly programming on Intel, and I originally learned the Intel syntax, and still I much prefer both reading and writing AT&T style syntax.

It's actually a nice thing, because now that I've had to read/write assembler for non-Intel platforms, I've been happy to have learned the AT&T once and for all, since almost every platform uses something quite similar.

If you see:

Code: Select all

  mov $foob, (%barf)

you immediately know that [tt]foob[/tt] is an immediate, and [tt]barf[/tt] is a name of a register, and that we are storing something immediate into a memory location, even if you had no idea that the target architecture had a register called 'barf'.

Now, ofcourse any proper RISC architecture would instead do it with explicit loads and stores, but that irrelevant.

[Brendan]

Hi,

My main problem with AT&T is that memory references can be both confusing and ugly. For example, compare "[eax*5+something]" to "something(%eax, %eax, 4)" - the NASM version looks like algebra while the AT&T looks like a C function. Even if AT&T only supported "(%eax*4+%eax+something)" I'd like it much more.


Cheers,

Brendan

[Candy]

There probably aren't that many like me, but I learned my assembly programming on Intel, and I originally learned the Intel syntax, and still I much prefer both reading and writing AT&T style syntax.

It's actually a nice thing, because now that I've had to read/write assembler for non-Intel platforms, I've been happy to have learned the AT&T once and for all, since almost every platform uses something quite similar.

Can't say using AT&T makes for much difference on multiple platforms. I've recently tried to help somebody with a bug in their c++ code. Compiled it to assembly and then I didn't understand scrat of the code left. Even though it was in AT&T which I can read (pretty much in full) for the structure of the language. MIPS code still requires learning it all again, same with 68HC11 and 8051, and also I think all the others.

[Pype.Clicker]

Hi,

My main problem with AT&T is that memory references can be both confusing and ugly. For example, compare "[eax*5+something]" to "something(%eax, %eax, 4)" - the NASM version looks like algebra while the AT&T looks like a C function. Even if AT&T only supported "(%eax*4+%eax+something)" I'd like it much more.


Cheers,

Brendan

I'd dare to say that, unlike intel's syntax, AT&T syntax wasn't meant for humans-written programs, but mainly for programs-writtent programs. Despite (%eax, %eax, 4) seems meaningless, it's easier to write code that will generate something alike whatever the ASM backend is and parsers that will accept it whatever the architecture is.

Just take two minutes in figuring out the nightmare GCC would become if it had to know subtle details of formatting for every architecture it supports. At least if you see %eax or %r15 or %g4 you know it's a register ... under intel syntax, the only difference between mov eax, ecx and mov eax, cex lies in the fact "ecx" is reserved and "cex" is not.

hope i made my point meaningful and not simply ranted ...

[bubach]

Thats not a good point.
It takes like two minutes to memorize the register names for a new platform.