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].
Joined: 09 Aug 2005
Location: Usono (aka, USA)
Re: Is FASM a good Backend language for creating a compiler?
I wanted to know if FASM was a good assembler language as a target language for a compiler.
The choice of assembler (i.e. program which translates mnemonics into machine code) is rather neglable here. You can really use any assembler you want and like. It is because assembler doesn't affect your code in any way - what you put on assembler's input is what you get in binary output.
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.
However, it's nice to choose project, which:
- is still maintained, so you're up to date with latest instruction set,
"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.
- has ports to all OS-es you want to support,
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.
- is fast (this point is also neglable as long as you don't use your toolchain on production).
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.
Also, syntax differencies between various assemblers are not so big, so if you'll prepare code generator for one, it should be easy to switch to another one if needed.
So my final advice is: don't think about what assembler to choose at the begin, just create working compiler first.
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.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum