Hello,
I started to use fasm as last stage in my compiler toolchain. I have generated x64 code with a lot of local declarations:



I found that above code generates "error: out of memory" message even if I set memory limit to 1GB or more (-m flag). Also I found that a lot of local variables make assembly process much slower.

I already found that I can skip this problem by using tmp[8192]:QWORD construction, but I think it's not desired behavior for assembler.

Is it known beheavior and does somebody investigated it before?

Thanks in advice.

The standard "proc" with "local" are defined as quite complex macros, and if you use these macros so many times, the source text grows quickly to large sizes (the assembler only starts processing the source text after it has gone through preprocessing in its entirety).

You could try using some customized macros with smaller implementation, so that the source text would not grow so large.

Alternatively, you could try fasmg with its set of fasm-compatibility Win32/Win64 macros. Because fasmg has no separate preprocessor/assembler layers like fasm 1, its macros use less memory. Your sample assembles easily with fasmg (with only problem being that "local" has to be replaced with uppercase "LOCAL" in current implementation of these compatibility macros), even though in that case even all the instructions are implemented as macros.

I have updated fasmg with a new experimental feature which I had in mind since quite a long ago and it allows me to finally implement "proc" for fasmg with case-insensitive "local" without causing any problems with usage of "local" directive inside instruction set macros. I may update the Windows headers to use this new feature soon, but then they are going to need the latest fasmg to work.

I understand. Thanks for quick reply.



I already switched to local .tmp[8191]:QWORD like constructon and calculate var offset manually while generating code in compiler. It's sufficient to go on with my current work. Result code is little less readable for human, but it's not a big issue for now.

I'll check out fasmg when earlier stages will be more stable. Thanks.

If this is a code generated by your own compiler, the best solution for you might be to make custom macro package, best suited to the code that your compiler is able to produce. fasm's "proc" is a large macro mainly because it implements many syntax variants for the manual use. In case of compiler output the macros may support just one simplified syntax generated by compiler and nothing else.