Passing command line arguments to FB programs

[jj2007]

In conclusion, all this can be summed up in a simple but high-level sentence:
The local variables are reserved on stack at procedure granularity only (including main part of program corresponding to main procedure), but not at individual scope blocks.

Which implies that defining local variables inside a scope block may look professional but has no positive effect on performance, because its space has already been reserved at proc entry...

[fxm]

Which implies that defining local variables inside a scope block may look professional but has no positive effect on performance, because its space has already been reserved at proc entry...

Not always:
- If there are several scope blocks in a procedure, a memory zone is allocated on the stack with a size corresponding to the scope block which requests the more of memory for its own local variables (not summing through all scope blocks).
- A same data address in stack memory can be used for different local variables belonging to different scope blocks.
- So, use several scope blocks in a procedure can save memory on the stack compared to all variables defined in the global scope.

[jj2007]

- So, use several scope blocks in a procedure can save memory on the stack compared to all variables defined in the global scope.

That may be an argument if you have heavily recursive procedures; by default, linkers assign 1.6MB of stack, iirc. The downside is that all dimmed variables, if they need initialisation, will get initialised inside their scope. Take this example:

Code: Select all

Sub testme(v1 as integer, v2 as integer)
  Dim as integer level0=&h12345678, ct
  asm mov eax, eax
  Print "  before Scope 1: ", level0
  for ct=0 to 9
	Scope
		Dim as integer level1a=&h1111111a, level1b=&h1111111b
		Dim as integer level100(&h100)
		asm nop
		level100(0)=&h100
		level100(&h100)=&h200
		Print "  Scope 1: ", level1a;" and ";level1b
	End Scope
	Scope
		Dim as integer level1b=&h22222222
		asm nop
		asm nop
		Print "  Scope 2: ", level1b
	End Scope
	Scope
		Dim as integer level1c=&h33333333
		asm nop
		asm nop
		asm nop
		Print "  Scope 3: ", level1c
	End Scope
  next
End Sub

Print "Program start"
asm int 3
testme(&h11111111, &h22222222)

The level1a=&h1111111a, level1b=&h1111111b etc variables are not modified any more, i.e. they are read-only, static, whatever you want to call that; and yet, the compiler assigns their values every time the Dim line is reached inside the for...next loop. Assigning them before entering into the scopes would speed up the loop dramatically. Admittedly a "constructed" case, but if you have a real life loop that does a Million iterations, this behaviour is to be kept in mind.

P.S.: The asm int 3 sets a breakpoint before calling testme; the &h12345678 or &j11111111 values can be easily spotted in the disassembly.

[fxm]

Your code is crashing on my PC (Win 7).

- When using "Static ..." in a scope block, the allocated memory is not on the stack and each static variable has its own memory allocation.
- When using "Dim ..." (without "= Any") in a loop, the variable is initialized at each iteration (an alternative could be to use "= Any", or otherwise "Static ...").

[jj2007]

Your code is crashing on my PC (Win 7).

There is an asm int 3 that permits to run it with a debugger. If you have a just-in-time debugger configured, Windows will stop at the int 3 and invite you to debug it. Otherwise, open the exe e.g. in Olly (but if you are not familiar with assembler, it will not be easy to see the assignments...). Anyway, your reply shows that you are already aware of this performance impact.

[fxm]

Which implies that defining local variables inside a scope block may look professional but has no positive effect on performance, because its space has already been reserved at proc entry...

Not always:
- If there are several scope blocks in a procedure, a memory zone is allocated on the stack with a size corresponding to the scope block which requests the more of memory for its own local variables (not summing through all scope blocks).
- A same data address in stack memory can be used for different local variables belonging to different scope blocks.
- So, use several scope blocks in a procedure can save memory on the stack compared to all variables defined in the global scope.

This optimization of the memory size allocated in the stack at procedure granularity (size corresponding to the scope block which requests the more of memory for its own local variables, and not summing through all scope blocks) is activated:
- always when using 'gas',
- only from the optimization level 1 when using 'gcc'.