flat assembler
Message board for the users of flat assembler.

Index > Main > Feature request: OMF et all

Author
Thread Post new topic Reply to topic
Juras



Joined: 18 Jun 2003
Posts: 23
Location: Belarus
Juras
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... Sad

_________________
Best Regards, Juras aka Exhu (aka YBX)
Post 21 Feb 2005, 22:14
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7751
Location: Kraków, Poland
Tomasz Grysztar
Quote:
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) ?

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

Quote:
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.
?

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.

Quote:
Will there be a way to output relocation info into ELF executable?

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.

Quote:
4) Will there by an acompanying disassembler?

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.

Quote:
5) Does FASM distinguish between Win32 COFF (microsoft) and GNU COFF (djgpp) ?

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".
Post 21 Feb 2005, 22:32
View user's profile Send private message Visit poster's website Reply with quote
bogdanontanu



Joined: 07 Jan 2004
Posts: 403
Location: Sol. Earth. Europe. Romania. Bucuresti
bogdanontanu
The OMF format is no way old and obsolete Very Happy
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 Razz
Post 21 Feb 2005, 23:54
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7751
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 22 Feb 2005, 00:14
View user's profile Send private message Visit poster's website Reply with quote
Juras



Joined: 18 Jun 2003
Posts: 23
Location: Belarus
Juras
Quote:

Quote:
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.
?

For the first option you can set some environment variables and do includes dependent on those variables.


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!!!!!!!!!!!!!

_________________
Best Regards, Juras aka Exhu (aka YBX)
Post 22 Feb 2005, 17:13
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Vortex



Joined: 17 Jun 2003
Posts: 318
Vortex

_________________
Code it... That's all...
Post 22 Feb 2005, 19:52
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Quote:

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.

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.
Post 23 Feb 2005, 12:54
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7751
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 23 Feb 2005, 13:20
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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 Smile
Post 23 Feb 2005, 13:51
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
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


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.