if declare a local variable with big size, fasm will always in the progress of compiling when compile this code:

proc myproc
locals
var1 dd 51200 dup (0)
endl
ret
endp

I see the esp's initial value is 0007FFC4, does it means the max size a local variable can be<0007FFC4? is there a way to extend the default stack size?

The problem is that you have to "touch" then stack at runtime else you will get access exception. See this thread for more information.

It fails to compile or it fails to run?

it fails to compile, but who declares initialized data in local variables?

I think touching will only help for running.. try changing 0 to ? to help it compile..

it fails to compile, even add following lines to proc32.inc:
repeat localbytes shr 12
mov byte[esp-%*4096],0
end repeat

yes, after change to rd 51200, it can be compiled. above three lines help to run.
tks.

Can you do it manually, without using macros, does it still not compile? I guess not right? (I don't use the macros anyway)

It doesn't really hang, it just enters a really long loop of virtual-load directives to generate MOV instructions that initialize the local variables for you. You really shouldn't use initialized locals that big - it generates 12800 MOV instructions (and for each one it virtualizes the whole block - really an overkill, but it's because of the limitations of "load"/"store" directives in fasm 1.x architecture). On my system it took 128 seconds to assemble and generated 500 KB executable.

Why does it need 500,000 bytes to make 12,800 movs? Is each mov 39 bytes long?

Because there are 51,200 MOVs. 9.77 byte per MOV, so it's possible (there are many MOVs with DWORD displacement and immediate - 8 bytes, and we must remember that there are two bytes more per MOV - one for opcode and one for mod r/m, so, the size of most MOVs is 10 bytes).

Yes, there are 51200 MOVs, my mistake, I thought it was "db" there, but it was "dd".

Why not use dword movs for dd?

They are dword movs already.

Oops x_x my math was all wrong. Sorry.

Interesting corner-case flaw, this thread should probably be in Macro or Compiler Internals forum.

The compiler would need extra logic to figure out whether it should generate the MOVs inline or use the REP loop if the number before the DUP is too large, or just use a REP prefix loop all the time.

It's not the compiler here, it's the macros.