FASM and NASM -- differences

Index > Main > FASM and NASM -- differences

Goto page Previous 1, 2

Author

Thread

Furs

Joined: 04 Mar 2016
Posts: 2565

Furs 25 Jan 2017, 13:47

revolution wrote:

Plus fasm doesn't support the "lovely" AT&T syntax

Oh yeah, I cringe everytime I do inline asm in GCC because I have to use it for compatibility. Even the "reversal" of the operands makes my head spin.

To be fair, AT&T syntax is definitely a bit easier to parse (for a computer), not for a human. It's sometimes useful if you want to parse/modify the generated code from a compiler automatically with a script. But not good if you want to manually inspect or code in asm obviously.

Also, FASM may have a lot of macros or weird syntax but it's because they give you a lot of power once you understand how to use them. You can use FASM macros to build arbitrary file formats and embed code in them with proper offsets and everything optimized because it does multiple passes on those constants generated by macros... I do that all the time. Why use bytecode of whatever script language when you can use x86 scripts? Maybe I'm old school but I prefer to only use x64 when needed (more than 4G of RAM per app or doing large number arithmetic etc, things that benefit from it).

25 Jan 2017, 13:47

rugxulo

Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)

rugxulo 26 Jan 2017, 00:41

Furs wrote:

Oh yeah, I cringe everytime I do inline asm in GCC because I have to use it for compatibility.

BinUtils' has supported ".intel_syntax" since GAS 2.10 (2000): "A new pseudo-op .intel_syntax has been implemented to allow gas to parse i386 assembly programs with intel syntax."

Furs wrote:

To be fair, AT&T syntax is definitely a bit easier to parse (for a computer), not for a human. It's sometimes useful if you want to parse/modify the generated code from a compiler automatically with a script. But not good if you want to manually inspect or code in asm obviously.

GCC 3.0 (2001) added "-mintel-syntax" ... "to emit x86 assembly code using Intel style syntax".

But I think newer ones prefer "-masm=intel" (e.g. GCC 6.3.0): "-masm=dialect" ... "Output assembly instructions using selected dialect. Also affects which dialect is used for basic asm and extended asm. Supported choices (in dialect order) are ‘att’ or ‘intel’. The default is ‘att’. Darwin does not support ‘intel’."

26 Jan 2017, 00:41

jorido

Joined: 23 Jan 2017
Posts: 53

jorido 26 Jan 2017, 16:50

system error wrote:

@jorido Macro in FASM doesn't really fit the definition of macros in NASM and / or MASM. FASM macros systems go beyond that.

Then why not to use C# or C++ instead -- their level of abstruction goes even more futher Very Happy

26 Jan 2017, 16:50

Furs

Joined: 04 Mar 2016
Posts: 2565

Furs 26 Jan 2017, 17:30

@rugxulo: Interesting, but wouldn't that conflict with inline asm made in AT&T syntax in other places? Or does the directive apply only within the current inline asm block? I'll check later when I can anyway. Smile

jorido wrote:

Then why not to use C# or C++ instead -- their level of abstruction goes even more futher

C/C++'s macros are actually piss poor compared to FASM. Rolling Eyes

Try create a data file with C++ macros or whatever you want, with no code even (without executing the program). With FASM you can even create your own "executable format" and it's simple with a few macros. For example if you use on-demand loadable code (like scripts), you'll likely prefer a custom tailored format than the bloated normal ones which assume a default executable.

26 Jan 2017, 17:30

system error

Joined: 01 Sep 2013
Posts: 670

system error 26 Jan 2017, 19:54

jorido wrote:

system error wrote:
@jorido Macro in FASM doesn't really fit the definition of macros in NASM and / or MASM. FASM macros systems go beyond that.

Then why not to use C# or C++ instead -- their level of abstruction goes even more futher

@jorido
Well, if such the case, then there's no point in using NASM in the first place. C++ wins over NASM in terms of abstractions, hands down. C++ has macros too, right? So why bother using NASM's macros, again? Wink

Macro is not just a tool for abstraction. In FASM it's also used as a tool of expression used by machine language compiler enthusiasts. The inventors of C/C++ also used these tools when crafting their compilers. Lookup semantic analysis, lexer, parsers, tokenizers, finite-state machines, scanner etc. This is part of FASM 'culture' and this culture is being nurtured using complex FASM macro languages and systems like FASMG.

Examples:

Using FASM's macro to parse Zilog Z80 instruction sets.

Emulating ARM architecture via FASM's macro languages.

Using FASM macro systems to emulate AVR instructions architecture

There are lots more if you look hard enough. I am not against NASM. It's a good assembler. Lots of references. But it's a x86 only assembler. It will be extremely painful to emulate any other incompatible architecture using its macro systems.

So comparing NASM to FASM in such naive x86-way is semantically invalid, null and void because ARM and Zilog programmers use FASM too!

If you can stay longer, maybe, just maybe I can grant you special lifetime membership of this board for free. That comes with free copy of FASM manual too, bro!

26 Jan 2017, 19:54

alexfru

Joined: 23 Mar 2014
Posts: 80

alexfru 23 Feb 2017, 11:54

I chose NASM long time ago when FASM either didn't exist yet or was in its infancy. I could use NASM for several different things (system code, DOS apps) and with several compilers (16-bit Borland Pascal and C; DJGPP).

FASM is great, but my C compiler needs some things only NASM and YASM provide out of the box (e.g. section fragment combining, 16-bit relocations in ELF files). I need to either preprocess the generated code specially for FASM or use some other hacks. I have a small tool to combine section fragments for FASM and perform conversion of the most basic assembler directives from NASM syntax to FASM syntax, which lets me use FASM for generating 32-bit protected mode executables (DOS/DPMI, Windows, Linux) just as with NASM/YASM. But for non-DPMI DOS executables I have to use NASM or YASM.

One thing NASM is bad at is optimizing jumps (choosing shortest possible jump instructions). When given a large file with several thousands of jumps it assembles pathetically slow. YASM and FASM handle this better.

23 Feb 2017, 11:54

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system

revolution 23 Feb 2017, 12:10

I think you are conflating assembling and linking.

Both fasm and NASM can generate object files (i.e. linkable files), with all the benefits of section coalescing and whatnot, via the use of an external linker.

But, AFAIAA, only fasm can generate executable files directly from assembly source, without any linker required. These files do not support any section gymnastics. But you don't have to use this mode of output if it doesn't work nicely with your HLL compiler.

Although, note that it is relatively easy to add macros to the source to allow section combining and executable generation in one step, no linker required.

23 Feb 2017, 12:10

alexfru

Joined: 23 Mar 2014
Posts: 80

alexfru 23 Feb 2017, 12:42

revolution wrote:

I think you are conflating assembling and linking.

I'm not sure about it.

revolution wrote:

Both fasm and NASM can generate object files (i.e. linkable files), with all the benefits of section coalescing and whatnot, via the use of an external linker.

I have posted about this problem before. FASM's output with repeating sections within the same ELF object file is problematic to link (see that other thread).

revolution wrote:

But, AFAIAA, only fasm can generate executable files directly from assembly source, without any linker required.

With a little bit of additional assembly code for the executable headers I can do the same with NASM. But it's irrelevant since I'm actually linking multiple object files and am not trying to make executables directly from assembly code.

revolution wrote:

These files do not support any section gymnastics. But you don't have to use this mode of output if it doesn't work nicely with your HLL compiler.

And I don't. But like I said, it's irrelevant.

revolution wrote:

Although, note that it is relatively easy to add macros to the source to allow section combining and executable generation in one step, no linker required.

I looked at some options, but ended up just writing a conversion tool. It's good enough for now. If/when it stops being good enough, I may revisit the issue.

23 Feb 2017, 12:42

Goto page Previous 1, 2

< 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