OSDev.org

I found this article on OSNews this morning, I thought it might be worth posting here.. because several developers can get rather confused reading AT&T syntax code when coming from an Intel syntax background.

Hopefully this will help those few who dislike one or the other learn about any possible advantages/disadvantages..

Linux assemblers: A comparison of GAS and NASM - By Ram Narayam

I'm trying to stay neutral on this, But I know it'll be worth posting it anyway

I still prefer intel...but now I can at least go through and understand what gas code does...

what I miss is that GAS uses different opcodes than what the intel manuals state, even beyond the suffixed b/w/l, like far jumps use the ljmp opcode, which means that in some os-related cases you'll have to figure out what the corresponding opcode is in GAS while in nasm you can simply copy the name from the intel manuals.

and then there's the fact that GAS is crippled when it comes to writing non-32-bit programs (or non-64-bit programs if you have an amd64 toolchain). Not really AT&T vs Intel related but worth considering since GAS is the only common assembler for that format.

Those are the main reasons for me not to write in AT&T syntax. I can read it with a bit of effort though...

Combuster wrote:and then there's the fact that GAS is crippled when it comes to writing non-32-bit programs (or non-64-bit programs if you have an amd64 toolchain).

I run on an x86-64 system and have no trouble compiling my 32-bit kernel using GAS. Passing --32 makes GAS behave as though it were targeting i?86 (if you compile asm through gcc, then use -m32 instead) and there's the .code32 pseudo-op, which is (IIRC) identical to NASM's CODE 32; .code16 and .code64 are also valid.
The only issue with 16-bit code I can imagine is problems with far relocations, which could also be a linker problem.

What syntax/assembler do you think the BSD's use in their bootloaders Combuster?

Your belittling of a perfectly working and efficient assembler is annoying...

I think that article is a giant "no duh" statement.

If you take the time to learn why all of that extra decoration is in AT&T syntax, and understand that crucial src/dest order difference... you are essentially training your brain to filter stuff so you can see the actual code.

I can attest from having to read MASM syntax, that it would be nice to know if something is a label/immediate/address/offset without having to jump through the rest of the code. On that point, I can see why people would want to use GAS over MASM.

However, all of the technical pros/cons in the world doesn't change the fact that people align themselves to something they can easily use and express. Prime example is all of the intel-based deviations. MASM, TASM, NASM and FASM are all generally the same but slightly different enough to cause a programmer to prefer one over the other.

Summary: Learning AT&T/Intel syntax if you are used to Intel/AT&T syntax is probably a good idea as it expands your understanding and gives potentially more access to source code, but don't invest in the hype if your preferred assembly language syntax simply works for you

SpooK wrote:I think that article is a giant "no duh" statement.

If you take the time to learn why all of that extra decoration is in AT&T syntax, and understand that crucial src/dest order difference... you are essentially training your brain to filter stuff so you can see the actual code.

I can attest from having to read MASM syntax, that it would be nice to know if something is a label/immediate/address/offset without having to jump through the rest of the code. On that point, I can see why people would want to use GAS over MASM.

However, all of the technical pros/cons in the world doesn't change the fact that people align themselves to something they can easily use and express. Prime example is all of the intel-based deviations. MASM, TASM, NASM and FASM are all generally the same but slightly different enough to cause a programmer to prefer one over the other.

Summary: Learning AT&T/Intel syntax if you are used to Intel/AT&T syntax is probably a good idea as it expands your understanding and gives potentially more access to source code, but don't invest in the hype if your preferred assembly language syntax simply works for you

wow...you are amazing...lol

hckr83 wrote:wow...you are amazing...lol

IIRC, he's a developer on the NASM project.

Alboin wrote:

hckr83 wrote:wow...you are amazing...lol

IIRC, he's a developer on the NASM project.

Yep. NASM and NASMX. NASM development is up to 0.99.05 now, many things have been fixed. We are really trying to isolate floating-point issues and an obscure ELF object format bug... and we should be off to NASM 2.0 fairly soon.

NASM 2.0 will be the first official and stable x64 support release. However, it actually works quite well right now as I am developing a 64-bit version of DynatOS using NASM as we speak

Combuster wrote:what I miss is that GAS uses different opcodes than what the intel manuals state, even beyond the suffixed b/w/l

Most of these differences came from history. And many of them are irrelevant to almost anybody, like clr, or smov/ssca/scmp etc.
Beyond the suffix (which came in also in Intel syntax for MMX and SSE, by the way) and what is covered below, what really matters are the two-suffixes operations, the equivalent of CBW and friends, where you have to learn that it reads c+srcSuffix+t+dstSuffix; and MOVSX/MOVZX where GAS drops the X (don't know why, makes it shorter?) and adds the two suffixes: quite frankly, it does not appear that complex to me, at least much more easy than the reversal of the operands or the % prefix.

Intel syntax also has some strange aliases, like XLAT/XLATB (not every assemblers have both); IRET meaning the same, or not, as IRETD (in 32-bit code); the type of the BOUND operand; or the stack operations for the 87 (FADD without operands, meaning FADDP st(1), st)

like far jumps use the ljmp opcode, which means that in some os-related cases you'll have to figure out what the corresponding opcode is in GAS while in nasm you can simply copy the name from the intel manuals.

Well, the far operations is where there are the largest divergences in any x86 assemblers, and this began with the early ones: Intel used JMP/CALL/RET with special types (including procedures), but DRI and many "tools" assemblers like DEBUG used JMPF/CALLF/RETF (+RETN), early Unix assemblers chose jmpi/calli/reti (i for intersegment, but it could be read intrasegment as well...), until ISC chose yet another one for the 80286 System V as, that is ljmp/lcall/lret (I do not know why).
All of this was before the mess created by the 80386 16/32 mixup, SMALL/LARGE or WORD/DWORD or DWORD/PWORD etc.

However, the main problem I have with these instructions is much more related to the difficulty to know the syntax, particularly whether the segment should come first or second, or whether the "clever" assembler will "simplify" my far call into a push+near_call . I believe I am not alone, since I often encounter code where the JMPF to 32-bit mode is coded as

and then there's the fact that GAS is crippled when it comes to writing [ 16 ]-bit programs

In this area, GAS made real progresses in the last years. What was really a mess 10 years ago is now almost doable.
Yes there are probably bugs remaining, but as in every GNU tool, there are (small) bugs because nobody use that code, and nobody use that code because there were (big) bugs.