1) Will there be sometime 16/32-bit OMF output support provided (for some high level lang. compilers and linkers to be used with FASM) ?

2) Will the command line be extended to recognize at least two arguments:
-dMACRO_CONSTANT[=value] (like NASM)
--rules - generates rules of dependencies on included files (like NASM) to be used in a GNU make file.
?

3) Will there be a way to output relocation info into ELF executable ?
4) Will there by an acompanying disassembler?
5) Does FASM distinguish between Win32 COFF (microsoft) and GNU COFF (djgpp) ?

Feautres 2, 3 and 5 are the most important for me.

These are the only features the lack of which prevents me from eventually using FASM in my C+ASM projects...

It was not planned, the OMF format is old and mostly obsolete. You might try some COFF2OMF tool anyway.


For the first option you can set some environment variables and do includes dependent on those variables. This is actually the only exception from the general fasm's rule that output (if successful) should be always dependent only on source and not affected in any way by command line. I see no reason why wouldn't you modify some includes instead of modifying the compilation scripts in a way to change some general constants.

The second one would need the whole compilation to be done anyway, since there is no other way to determine which files will get finally used and which not, fasm's features are too extensive (the files read by the "file" directive, the "on" setting of PE format, etc. - would also be needed to put into dependencies list, so only preprocessing wouldn't be enough, as all those features could be affected by pass-dependent conditionals). So it wouldn't make any sense for "make" process anyway. On the other hand fasm should be fast enough to rebuild the all files every time, so just forcing "make" to run whole fasm compilation every time should be OK.


If you want relocations, use the "regular" ELF output. The executable formatter variant was designed just to write small self-contained assembly programs, without any references to external libraries etc.


Might be in some far future (as I was planning to make it for a built-in into IDE debugger). But right now I've got enough work with the assembler itself to fill my spare time.


This question is actually covered in manual. You select the Microsoft's COFF variant with "format MS COFF" directive and the djgpp's one with "format COFF".

The OMF format is no way old and obsolete
It is the format that is supported by Intel itself so calling it names is at least a funny perception of reality ...

The fact that Microsoft choosed to use a variation of COFF and that Unix/Linux uses COFF/ELF dosent make it new and adavanced by default

The fact that Intel uses it also doesn't make it any better; they were using this format in old days and they continue it, expanding with new features as needed. But because of it this format is much overblown and when choosing the format without need to keep some kind of "backward compatibility", the choice of some newer one with much cleaner specification was for me evidently better.

Well environment variables are not appliable for me, however -d option is for convenience when using conditional compilation (e.g. __DEBUG__ and __RELEASE__ versions)...

Nevertheless, OK I'll find the ways to solve these issues. However, would you please add all these to the FAQ someday? And many THANKS for the help and attention!!!!!!!!!!!!!

Coff2omf tool:

ftp://ftp.digitalmars.com/Digital_Mars_C++/Patch/COFF2OMF.zip

debug/release selection is one thing, but the ability to quickly tweak parameters for testing various configurations can be very useful too - an example would be tweaking a memory manager, selecting chunk and bucket sizes.

So you quickly tweak some configuration file designed for this (and included into source). That's fasm's approach: command line is for fasm's settings, and for your programs' it's the source.

It's still faster and more convenient to tweak those parameters from the commandline, as this can be done by a batch file or shell scrript. I don't really see the problem with a "-dSYMBOL=VALUE" option, but well, it's your tool