Which Assembler should I choose

[qw]

You want an include? It has to be relative to the working directory, and not the source directory because getting the latter is apparently an impossible task to do portably. (And yes, I was really given that explanation once )

Whatever you think of it, portability is a major design goal of NASM so the explanations is not that strange.

[Casm]

Apart from GAS, which has horrible syntax, it doesn't matter much. I have done quite a bit of assembly language in the past, so I prefer a masm type clone which doesn't force me to change the habits of a lifetime, but, other than that, it doesn't matter much.

[Brendan]

Hi,

In my opinion...

MASM, TASM and a few others (a86/a386) aren't open source and can't be ported to your OS one day, and therefore should be ignored. MASM should be ignored twice because it tries to pretend to be slightly higher level; and the end result of that is you can't look at a simple line of source code and know what it does (e.g. "mov eax,foo" may load an immediate value into EAX or load a value from RAM into EAX, depending on how 'foo' is defined) and this makes it harder to write/maintain code.

GAS is mostly used for AT&T syntax; and AT&T syntax is ugly/confusing. For example, for "[1234+ebx+ecx*4]" (Intel syntax) it's obvious what is happening; but "$1234(ebx,ecx,4)" (AT&T syntax) doesn't look anything like what it does. GAS does support "Intel syntax" but it's an after-thought rather than something that works like it should. In addition, the pre-processor for GAS is severely underpowered and can't handle anything tricky. Note: If you're writing most of your project in C and are also using a small amount of inline assembly and a small amount of "stand alone assembly", then it does make sense to use whatever the compiler uses (e.g. to avoid the hassle of dealing with different dialects of assembly). For GCC this would mean using AT&T and GAS. However; this is almost never the case - typically the inline assembly is so small that you can ignore it and use anything you like for the "stand alone assembly".

FASM seems "mostly good". However; before using FASM you should look at FASM's source code - it's extremely bad (unreadable and unmaintainable). Due to how bad the source code is, there's no way I'd be willing to trust it to get anything right. Note: For high level languages you don't really need many comments because variables, etc are given (hopefully) meaningful names and the code (hopefully) does what it looks like it does. In assembly neither of these things are true - e.g. the register name "eax" tells you nothing about what is in the register; something like "lea eax,[ebx*5]" might be used for arithmetic and may not be being used to load an effective address at all; "shr ebx,3" might be used for division and not for shifting right; etc. Because of this; good assembly requires a lot of comments. FASM's source code has no comments; and even where meaningful names could be used (labels) it uses "nonsense names" instead.

This leaves NASM and YASM. They're both "good" (good documentation, good/powerful pre-processor, the most sane dialect of "Intel syntax" I've seen, etc). They're also both very similar - the pre-processor, directives, "Intel syntax", etc that they use are almost exactly the same; which means that it's extremely easy to switch from one to the other without changing very much of your source code (and with a little care it's easy to write code that can be assembled with either assembler without any changes). For which is the most up to date, they seem to take turns (NASM is currently more up to date, but it wasn't a few years ago and might not be in a few years time) but this doesn't matter much because it's relatively easy to switch from one to the other. The main difference between them is that YASM also supports AT&T syntax and NASM doesn't (but I wouldn't recommend using AT&T syntax anyway).


Cheers,

Brendan

[Kevin]

I generally tend to use gas these days, mainly for the reason that I'm using gcc for the C code and therefore already use gas indirectly. This way I get the same syntax and features in inline assembly as I get in my external assembly files (and objdump uses the same again by default), and I avoid an additional external build dependency.

As for the syntax, I don't care. It's just a stupid notation, there's not any difference in the idea behind it. Anyone who can't get his head around a different syntax shouldn't even dream about working on something as complex as an OS, because OS development would definitely ask too much of him.

Note: If you're writing most of your project in C and are also using a small amount of inline assembly and a small amount of "stand alone assembly", then it does make sense to use whatever the compiler uses (e.g. to avoid the hassle of dealing with different dialects of assembly). For GCC this would mean using AT&T and GAS. However; this is almost never the case - typically the inline assembly is so small that you can ignore it and use anything you like for the "stand alone assembly".

Yes, this is exactly my case. The inline assembly is indeed quite small, but so is the stand-alone assembly. The amount of stand-alone assembly simply isn't worth dragging another tool into the toolchain (that wouldn't even be objectively superior, just equally usable). And consistency never hurts, no matter how much code it affects.

the pre-processor for GAS is severely underpowered and can't handle anything tricky.

Honest question: What kind of features do you think of here? I've never met any situation where I thought I'd need a more powerful preprocessor, but then my amount of assembly is - as I said - minimal.

[Yoda]

Brendan, good post!
That's the way I think but you are really kind to thoroughly verbalize all arguments.
I don't like FASM too (because I too looked at the sources) but the reason I recommend to try it is a huge number of its adherents and that it actually works (despite bad sources).

Honest question: What kind of features do you think of here? I've never met any situation where I thought I'd need a more powerful preprocessor, but then my amount of assembly is - as I said - minimal.

That's the reason - minimal. Try to make something large and you'll face necessity of powerful macro language - printing messages, multipush/pop, structures (like GDT), incorporating binaries, sharing fragments of source and many other things - all "the must".

[Gigasoft]

I like to use JWASM, which is (almost) compatible with MASM. Other assemblers often seem to require too much verbosity.

[Brendan]

Hi,

I generally tend to use gas these days, mainly for the reason that I'm using gcc for the C code and therefore already use gas indirectly. This way I get the same syntax and features in inline assembly as I get in my external assembly files (and objdump uses the same again by default), and I avoid an additional external build dependency.

As for the syntax, I don't care. It's just a stupid notation, there's not any difference in the idea behind it. Anyone who can't get his head around a different syntax shouldn't even dream about working on something as complex as an OS, because OS development would definitely ask too much of him.

In that case, let's deliberately obfuscate the syntax and have weird stuff like "<&0; %k 9]" and then pretend it makes no difference because it's just notation. Anyone that can't get their head around "& <!>> g{!}" isn't smart enough to wonder if there's a cleaner or more readable way...

the pre-processor for GAS is severely underpowered and can't handle anything tricky.

Honest question: What kind of features do you think of here? I've never met any situation where I thought I'd need a more powerful preprocessor, but then my amount of assembly is - as I said - minimal.

I think of just about everything described in the relevant part of the NASM manual - I've used it all at one time or another for something.

Ironically; normally I don't use the pre-processor that much for code - most of the time I use it for generating data. For a simple example, a while ago I decided to add standardised metadata to all my OS's native file formats; and (after writing the specification) spent about 20 minutes writing macros to do things like "METADATA_AUTHOR Brendan" to make it easy to generate the metadata and insert it into its section of the file.


Cheers,

Brendan