Randall Hyde had once written a dedicated benchmark for testing the speed of various assemblers, look here.
If you wanna see some of the test results that was made for fasm (and some speedups that were done), look into this thread.
However I haven't benchmarked the latest fasm's versions yet.

> and gas uses one that is a bit easier to parse.

GAS has been supporting "intel syntax" also for 11 years.

> Randall Hyde had once written a dedicated benchmark for testing the speed of various assemblers, look here.

Link is broken.

The original link may have been broken, but the benchmark was posted as an attachment in the second thread I linked here (and the first thread metions this fact).

thers no diffrence betwen fasm and other asemblers. They all output same code, only syntax differ.

Oh how true that is NOT!

very not true.
if fasm cross a [esi+0], it will not generate a [esi+0], but a [esi], so, fasm parser is an optimal choice for asm coding.

2 edfed
I think it is a miss. Even typing "dword 0" fasm refuses to assemble (
Tomasz if U read it maybe it is possible to fix it?

More or less, I'd argue the difference lies in the macros.

Some things like inlining functions is very hard to do well without some high level macros because you want to figure out which registers are best at compile time.

I'd actually be tempted to integrate a scripting language into a table-driven assembler. You could assembler and disassemble, and you'd be able to do alot more during compile time to make sure everything is exactly how you want it.

Extending the scripts, you could (easily?) make it a debugger too. : p

Just a casual thought.

FASM lacks the ablity to return a value from macro - inline macros are very useful. Sometimes EQU can be used, but usually a more complicated macro is needed and isn't visually appealing to me.

Yes indeed.
However, do keep in mind that with the speed of today's machines, most assemblers will compile any reasonable-sized file instantaneously, so the speed advantage isn't that important anymore. Back in the days when it took 30 seconds to compile a file, assembler performance was very important. But most projects today will compile in under a second or two, so performance is really more of a "bragging right" than anything else.


As tomasz has pointed out already, I've done some of this in the past, but...



Comparison is difficult, but not because of the "easier to parse" issue (which, quite honestly, isn't really true for Gas vs. FASM). Some assemblers (such as MASM, TASM, and HLA) are loaded with a lot of features that make them *much* larger that other assemblers and that has a much bigger impact on performance. Some assemblers (HLA) use crappy symbol table lookup functions, that has a much bigger impact on performance. One reason FASM is so fast, for example, is that it is quite small and the program fits entirely in cache (even on older machines). That has a *big* impact on performance compared with larger assemblers that are constantly moving data in and out of cache from main memory.

The real reason comparisons are difficult, however, is because assemblers vary greatly in their feature sets. For example, FASM, Gas, and NASM are all "low-level assemblers" that don't support HLL-like constructs like MASM, TASM, and HLA do. Sure, we could write programs in a subsets of these assembler's languages, but that's not how real MASM, TASM, and HLA programs are written. So would the comparison be valid? And even ignoring the HLL-like features some assemblers possess, almost every assembler out there has a different concept of macros. And macro expansion is one of the more expensive operations an assembler can do during compile time. Again, do we ignore the use of macros in our benchmark files? That wouldn't be very useful as most reasonable assembly language programs make use of macros.



Very simple. Just write a decent-sized HLA program and use the "-sf" and "-sg" command-line options to translate the program into FASM and GAS source code. While you're at it, you may as well do "-st" (TASM) and "-sm" (MASM), too.

I never ran the benchmarks against Gas, but in the past I have found the following approximate ordering by performance (fastest to slowest):

TASM
FASM
MASM
NASM

However, my results are very old. TASM has never been updated, but FASM, MASM, and NASM have been. YMMV.


Less important than you think. HLA, for example, can use MASM, TASM, NASM (HLA v1.102), and Gas as "back-end assemblers". Given the simple (instruction-only) source output that HLA produces, there is almost no impact on compiler performance by the choice of assembler (well, with the single exception of MASM6 when you declare a large static array -- a known defect in MASM6).

To me, a bigger concern would be the support of the entire x86 instruction set. Currently, FASM has the best support for all the x86 instructions (even better than Gas). If you intend to use certain SSE instructions with today's versions of Gas and FASM, I think you're better off with FASM at this point. Then again, Gas will, no doubt, be updated before too much longer.

MASM and TASM are bad choices (OS-specific, continuing support issues). NASM is a good choice from an instruction set point of view (and it's actually getting support these days), but I've not measured the performance of NASM 2.02 so I don't know how much better the performance is than it was back in the NASM 0.98 days (which was really bad).


Yes, that's how I've done it in the past.

Finally, are there any current x86/amd64 assemblers which are even faster than fasm?
[/quote]

The last time I ran benchmarks, TASM was faster. But not fast enough to justify using a closed-source/unsupported/32-bit-only/OMF-only/Windows-only program.
hLater,
Randy Hyde

And iirc only present for COFF and not OMF object files? (the COFF implementation could still be sped up though, and probably by a very large amount, although it does need to write all the bytes to disk).

Actually, I ran into some problems recently with the OMF->COFF conversion that the Microsoft linker does. Unless this problem has been resolved, I would be *very* careful about relying on that translation to fix the COFF generator performance problems.

In any case, I don't particularly recommend MASM as the back-end to a compiler. It has enough idiosyncrasies, plus the fact that the version that everyone has (v6) doesn't support much beyond the basic MMX instruction set, is a problem.

To the OP: One of these days I will post HLA v1.102 to http://webster.cs.ucr.edu. This version has a completely rewritten instruction parser and code generator. In particular, it supports hexadecimal output of all instructions as well as source output for MASM, TASM, NASM, Gas, and FASM. Though it was a *lot* of work to provide all the difference source code output formats, I feel that it's worth it. When HLA v1.102 comes out, you might grab the "output.c" source file (that contains all the code to emit all the various instructions in all the various output formats) and use that as a template.
Cheers,
Randy Hyde

randy: looking forward for next release of library, so i can point out more bugs and design glitches

The assemblers all seem to do it in <0.5s for <80kb source programs. At some point, doesn't it get trivial?

I concern myself more with features that will actually save me time. For the assembler itself, making it capable of flat and EIP-trace disassembly would save me alot of time.

For an IDE, being able to drag and drop snippets, have proper flow-control graphing, and register tracing and range graphing, and a forwards and backwards capable assembler at the back-end would make coding assembler easier than most HLL's.

I'd be willing to help. To be honest I find it sad that we create immersive 3d games but are still stuck typing text into a plain editor and running the command lines when we code.

Regards,
Dan

Actually, I've been working on an HLA->NASM translator.
Compiling the FASM v1.66 source code (translated to HLA source code, which I use as a back-end for HLA), HLA reports 71593 lines of source code processed (after macro expansions). It compiles this in about 0.512 seconds or 139830 lines/sec (this is about half the speed of FASM measurements I've made). This produces almost 60,000 lines of NASM code with no macros. NASM v2.02 requires about 12 seconds to process the output.

I was told that NASM had been sped up considerably between the 0.98 release and the v2.02 release. However, performance could obviously be improved a bit as most other assemblers do the same thing in well under one second.



Well, feel free to continue the FRESH project
hLater,
Randy Hyde

I'm afraid the next release will be a disappointment, then.
Currently, my plans for the next major release (assuming no show-stoppers in the meantime) is a port to Mac OSX. There really won't be much in the way of new code, new designs, or anything like that. Just a port.
hLater,
Randy Hyde

I ran the 30,000+ line source file through FASM and it took about 0.1 seconds to process. So actually, FASM measures about 2.5 times faster than HLA, though FASM is processing very simple compiler output (versus HLA which is processing a lot of macro code). In any case, let's call the performance difference 2.5 times.

Whatever, I still would argue that if performance is a high priority, NASM is probably a bad choice for a back-end assembler. OTOH, if portability is a goal (that is, getting your compiler to run on as many OSes as possible), NASM is a good choice as it's available on more OSes than even Gas.
hLater,
Randy Hyde

The problem that I see with NASM is that it is not self contained, it requires a C compiler. The advantage I see with NASM is that it is not self contained, it uses a C compiler.

Ah, sometimes life seems so confusing! Sometimes problems become advantages and advantages become problems.

If the whole world never used non-x86 CPU's then I wonder how much of daniel.lewis' vision would have come true?

lol, I actually started ASM using NASM, then when I created my first program I realized NASM actually didn't make executables .