The flexibility of FASM/G allows using it to create new compiling/assembling solutions that are effectively pre-processed such that concern about FASM/G build times is a fallacy, and one need only use FASM/G (Compiled Macros) to create their own tools that build faster, e.g. for a specific CPU?

For example, FASM2 uses FASM/G and it's not significantly slower than FASM?

I.e. Help people understand the true power that FASM/G offers? I.e. Need to understand the whole point of FASM/G and the power it provides?

A key point that I am seeking to have addressed is the idea that FASM/G build times relative to FASM may be seen as a reason to not use FASM/G for compiler development, yet the tools produced by FASM/G can be much faster than any Rust or even C compiler?

If build times were an issue, initial startup for a particular environment could be cached as part of the system support -- the same could be done for fasm, too. (Analogous to the pre-compiled headers, [s]ccache, modules of the high-level languages.) To my knowledge, no such effort has ever been made.

Post from 2020. May cause concern for those considering FASM/G?

https://board.flatassembler.net/topic.php?t=21488

It is from 2020, so perhaps improved now and/or perhaps when understood in the context, it's not an issue at all, hence my OP.

For my use case fasmg is considerably slower than fasm and does cause anguish. There is a trend in software development to add more layers of abstractions and hobble code with more "baggage" making it slower and more resource hungry. I have a fast computer, dammit, I don't want to make it slower each time new code comes along. Other examples of this effect are MS Teams and all the electron apps.

In addition to performance is the extras that fasmg needs to make it a complete assembler with all the required extra supporting macro files. Zipping up a project with asm sources and the assembler and sending it as a stand-alone package to a another customer/client/user requires also sending all the extra support macros along with it to make a complete set. It complicates the process and clutters up the package with extra bloat. For small projects with a single asm source file the bloat is very noticeable and degrades the experience, compared to needing only one exe for the single asm when using fasm.

Keeping older versions available for fasm is easy, we just have each exe file with the version number appended to the filename, so assembling old code is straightforward. Supporting simultaneous older versions in fasmg needs a lot more work to setup separate folders to hold all the macros and have ways to specify those folders when assembling with different versions.

That is my experience with fasmg.

Sincere sympathy, but again, FASM/G is still _much_ faster than Rust, C++ or even C compiler?

Agree! That's why I avoid Java and .NET and bloatware in general. Some exceptions, e.g., sometimes generics, such as list<T>, in a language are OK, provided that they are implemented efficiently.

That's related to my OP. A product based on FASM/G, e.g. FASM2 may be a bit slower than FASM but not much? Does FASM2 performance extrapolate to a compiler based on FASM/G? Is this basically moot because still, FASM/G is faster than even a C compiler? These are my key questions that I still seek an answer to.

fasmg doesn't compile C code. And C compilers don't assemble asm sources. I don't see how those can be compared in a meaningful way.

Perspective.

Modern compilers function less as monolithic translators and more as modular platforms or orchestrators. They act as a central interface (often called the Compiler Driver) that coordinates a pipeline of specialized components and exposes internal data structures to external developer tools.

Compiler drivers do process/assemble asm sources. For GCC the assembly tooling is separate, but Clang has an integrated assembler (which can be bypassed for the traditional external tool). This impacts both inline assembly and stand-alone files.

MSVC is a different beast - no inline assembly support - must use intrinsics or external assembly code. In that regard you are completely correct, but the other cases are more complicated as the compiler driver makes assembly integration seamless with other language support.

Yet, I agree with the comparison to fasmg being largely invalid. fasmg is somewhere between the compiler drivers and monolithic translators (fasm, tcc, etc.).