I was searching the internet to see if there were by chance any "Optimizing Assemblers" that optimized assembly code.
There are a bunch of links to different universities, and emails and papers written by students and professors. but no links to actual products.
===============================================
In order to optimize assembly you would need to scan the code for function calls and push the variables the function uses onto the stack before the call.
Optimizing FB
Optimisation of the assembly code is only a partial solution. Optimisation of the high level language will also yield a significant improvement. Most optimisation has been focussed on the C languages which is one of the reasons for creating the C emitter for FB. That way FB will benefit from the C optimisers without having to do the optimiser development work.
Optimisation mostly isn't done afterwards but during the compiling process itself (backend). There are several optimisation possible targeting different inefficiencies. Optimisations also depend on the architecture of the compiler itself, e.g if register reloading is used.
Myself I spotted one point the compiler should optimise:
Each local variable is accessed up to 3 times:
1 It is first reserved using something like "sub esp, XXX" done for all variables together.
2 The variable is initialised with zero or the value assigned in the declaration line.
3 The variable is then used with the code
Step 2 is often unnecessary, since there are lots of cases when there is written an value to it by the code, before the variable's value is read the first time. Therefore code could be optimised by doing the zero initialisation not by default in the beginning, but only if the value read before writing.
Myself I spotted one point the compiler should optimise:
Each local variable is accessed up to 3 times:
1 It is first reserved using something like "sub esp, XXX" done for all variables together.
2 The variable is initialised with zero or the value assigned in the declaration line.
3 The variable is then used with the code
Step 2 is often unnecessary, since there are lots of cases when there is written an value to it by the code, before the variable's value is read the first time. Therefore code could be optimised by doing the zero initialisation not by default in the beginning, but only if the value read before writing.
There are plenty of arguments to assign zero automatically by default. Beginners are protected by variables that default to zero on declaration. Once they learn to write FB and speed becomes more important to them, then they can declare variables where first used, or earlier with “any”. Most beginners declare variables in a block at the start so time is wasted assigning zero only once. Pointers declared, but not specifically set to a valid address can be trapped as a null pointer.
So yes, it is possible to flip the convention to automatically assume “any” and not assign zero.
Unfortunately that would break all legacy code written using the knowledge that declaration set zero.
When an optimising compiler becomes available it will resolve this matter since an optimising compiler is able to recognise the possible reading of a variable before the first assignment. That is the solution you may be suggesting. But all optimisation should probably be left to the one optimising compiler following the C emitter.
So yes, it is possible to flip the convention to automatically assume “any” and not assign zero.
Unfortunately that would break all legacy code written using the knowledge that declaration set zero.
When an optimising compiler becomes available it will resolve this matter since an optimising compiler is able to recognise the possible reading of a variable before the first assignment. That is the solution you may be suggesting. But all optimisation should probably be left to the one optimising compiler following the C emitter.
Return to “Community Discussion”
Who is online
Users browsing this forum: No registered users and 6 guests