AFAIK, golink don't always agree with NASM's sections setup either. For example, aligning your section .bss is impossible if there exists a section .data somewhere in the code. In this case, you need to manually setup your .bss section alignment right from inside the .data section. You'll be in trouble if you have XMM or YMM data reserved in the NASM's bss section while using golink. To this date, there's still no fix from either sides.

I think this is a problem of linkers, not the assembler per se. In some cases, code or data fragments may induce its own penalties and drawbacks.

OTOH, I see a significant improvement coming from Microsoft LINK which I believe was written in C++. It's lightning fast and deals with section fragments gracefully.

The overall picture is that all C-based assemblers and linkers seem to be POSIX-compliant and don't really fit into the FASM way of doing things which I believe was designed with 'flatness' from scratch. Why? C is a modular language where everything is a function and the data are placed on the stack. This kind of design is considered a "legacy" from modern CPU standpoint. Leaving sections fragmented all over the memory space is a "legacy" habit.

But don't get me wrong. NASM is a good assembler, if you chose the POSIX / C path. It has its own advantages. OTOH, FASM is raw and closer to how the CPU works. Well-proven by MenuetOS/KolibriOS and rwasa (a web server) written by redsock. [redsock, buy me a beer].

End of clueless opinion.

Well, it's a bit more nuanced than that.

Sure, bare-bones "Intel" syntax is fairly similar, but anything more than that gets thorny. For the most part, one instruction only has one encoding, so that part doesn't depend on any specific assembler. But assembly is more complex than just raw instructions.



"Up to date" as in bugfixes? Eventually development will slow or stop. Nothing keeps getting developed forever. Sometimes "good enough" is good enough for average use.

"Latest instruction set" ... are you really wanting to target AVX-512 in your compiler?? Maybe so, but overall, most compilers don't even use SIMD, even for the integer stuff. I'm just saying, "new" instructions are (mostly) ignored, and I don't really blame them.



The only OSes that anybody "supports" or really uses anymore, for the most part, are the big three: Mac, Win, Linux. Anything else is too weak for heavy use, apparently. Honestly, we all rely too much on billion-dollar OSes, which is probably not wise for future compatibility.



Fast is relative. Does it support SMP / multi-core? GPGPU? I don't think people notice speed as much anymore. Certainly the assembler is probably not the most problematic tool.



FASM hosts and targets on Windows and Linux and others. It supports PE/COFF and ELF linkable objects, so yeah, it's probably good for a compiler backend, assuming that does what you want.

I do question what other assemblers are even considered viable these days. Obviously MASM or NASM or YASM are good choices. But there really aren't that many others, are there? GoASM? (Some people still use GAS, but I think overall it's too flawed.) Let's not be naive, some other third-party assemblers are too weak.

P.S. Obligatory link to Wirth's Compiler Construction free e-book.