ASM Syntax in the OS FAQ...

[Dreamsmith]

...and that, if anything, this argument here showed that we should figure out some way to have examples in both syntax, side by side.

Indeed. Aside from making things more approachable by anyone, "Rosetta stone" side-by-side examples do wonders for people who know one syntax and want to learn the other, and personally, I think everyone ought to have some degree of fluency with either syntax, regardless of which they prefer.

[Schol-R-LEA]

I believe I can provide such, and do so in an idiom that is familiar to many of us. A while back, I translated my boot sector into GAS as an excercise for this very purpose.

However, I cannot guarantee that it the AT&T version is perfectly working; the code assembles, but I was never able to work out how to generate raw binaries from the object file. Also, there are some minor differences between them (at least I hope they're minor) in the text data and in the use of macros.

HTH. Any corrections (or help in testing the AT&T code) would be appreciated.

[Pype.Clicker]

Okay, dudes, http://www.osdev.org/osfaq2/index.php/NasmAllInOne contains all the GAS examples translated in NASM ...

If anyone wants to help for NASM->GAS translation, i know details of this less better ...

[Candy]

But I won't. I just say that you will encounter AT&T syntax when disassembling your kernel using objdump, and that you can use AT&T source examples without having to install / handle another tool...

Well, this is exactly what everyone using only AT&T will tell you. Note that objdump has a flag that makes it output Intel-style code. For an example, see my makefile / dump file from kernel. They're fully intel-style.

[Solar]

Candy, the point in such discussions is that both sides have perfectly good arguments...

The reason why forums populated by less socially skilled people than our lot here tend to degenerate into flame wars is that usually both camps reiterate their arguments over and over, deny the validity of the other side's arguments, and never come to a conclusion. >:(

Our conclusion is to provide "translations" in a seperate page. (Good thinking, Pype!)

[IRBMe]

To be honest, I much preffer reading intel syntax. I find it much easier to read and clearer, probably because I'm just much more used to it.

Displaying NASM syntax is great for people writing 'part being explained' in asm since they'll probably be using NASM.

On the other hand, displaying AT&T style syntax is good for people writing 'part being explained' in inline asm using gcc, since it uses that style.

If I were to have a choice, I would say it would be best to have both syntax' side by side to compare and choose.

If I had to pick one, I would go for the intel-style NASM syntax.

[IRBMe]

Just as a side note, there is actually a good tutorial located here:

http://www.osdever.net/tutorials/gccasm ... ?the_id=68

Showing you how to write inline asm in gcc. This is how I figured out the basics.

[Pype.Clicker]

Should inline-asm examples for GCC be translated aswell ? i don't really feel like giving "pure-nasm functions that you can use instead of proposed inline ASM" ...

there's the .syntax intel,noprefix trick, but does it worth the conversion ?

[Solar]

I don't think so. The InlineAssembly parts are primarily aimed at people who would like to avoid ASM altogether and not leave cozy C space at all; as such, I doubt they'll have a "preference" as to which ASM syntax to use.

Writing inline ASM yourself requires some intimacy with the GCC toolchain as a whole, and that too speaks for the person in question being somewhat familiar with AT&T.

Then again, I'm from the AT&T camp (because it's "cleaner" and more like the 6502 / 68000 ASM I am used to), so my word doesn't really count, now does it?

[Candy]

Candy, the point in such discussions is that both sides have perfectly good arguments...

So true. Yet, I'm from the Intel camp, it is superior to at&t and the statements in this line are 66% true. (that is, it's not superior. Its different)

The reason why forums populated by less socially skilled people than our lot here tend to degenerate into flame wars is that usually both camps reiterate their arguments over and over, deny the validity of the other side's arguments, and never come to a conclusion. >:(

what forum contains more nerds than an OS dev forum? Yet, they know that discussing the content of an issue is more productive than discussing the packaging (they discuss the code, not the style). If there's a difference, you clear it up anyway. The code doesn't matter.

That being said, for beginners and novices using one language alike, it's very useful to have both alongside.

The reply was mainly to counterpoint one of your arguments why AT&T would be better, not to get a reply.

[Pype.Clicker]

Well, this is exactly what everyone using only AT&T will tell you. Note that objdump has a flag that makes it output Intel-style code. For an example, see my makefile / dump file from kernel. They're fully intel-style.

hmm ... nice to learn this ... however, that '--disassembler-options=intel' flag doesn't seem to handle "db 66" properly (it just says "data 16", but still show the line as "cmp DWORD PTR" in 32-bits mode ... hum hum.

[Dreamsmith]

Then again, I'm from the AT&T camp (because it's "cleaner" and more like the 6502 / 68000 ASM I am used to), so my word doesn't really count, now does it?

Heh. I used to code 65C02/65816 stuff quite a bit, and I once wrote a 65C02 emulator in 68000 assembly language. I hated Intel syntax when I was first forced to deal with it. After a while, though, it kind of grows on you...