This might make sense if your project is written entirely in assembly, but does anybody even do that nowadays? For projects that are mostly in C/C++ with bits of assembly here and there, it's yet one more dependency your users have to install.
This might make sense if your project is written entirely in assembly, but does anybody even do that nowadays? For projects that are mostly in C/C++ with bits of assembly here and there, it's yet one more dependency your users have to install.
Contrast that to typical AT&T-syntax x86 assembly with bunch of meaningless punctuation and complex addressing modes represented by bunch of comma separated numbers. And with MASM that needs bunch of boilerplate and noise words, because the syntax is motivated by what was required to produce real-mode 16b object files.
For any reasonable amounts (say, you want a function or several) of assembly, you want Intel syntax and standalone assembly files.
NASM is a great tool, although YASM should also be mentioned: https://yasm.tortall.net — YASM is what I used when I optimized an H.264 decoder for Intel-compatible CPUs way back in 2005 or so.
It's trivial to enable Intel syntax in inline assembly even under GCC. And if you're using Rust instead of C or C++ then the inline assembly syntax is actually really great and very pleasant to use.
And while that in itself is maybe not particularly exciting, I think the underlying point is more that assemblers like nasm allow for the implementation of toolchains like this, where you have some assembly with some C code. While not common, I'm sure cases like this are also not exceedingly rare.
The data generation stuff is better aswell.
This was a while ago, and I could have missed these features else where, but that's why I ended up at nasm.
Yes, if youre just doing a bit of assembly, use whatever, but if you're doing a bigger project in assembly, nasm is optimised for that, rather than dealing with the output of a compiler.