Optimizing FB

For other topics related to the FreeBASIC project or its community.
albert
Posts: 5927
Joined: Sep 28, 2006 2:41
Location: California, USA

Optimizing FB

Postby albert » Dec 04, 2011 0:57

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.
Richard
Posts: 3047
Joined: Jan 15, 2007 20:44
Location: Australia

Postby Richard » Dec 04, 2011 2:40

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.
MichaelW
Posts: 3500
Joined: May 16, 2006 22:34
Location: USA

Postby MichaelW » Dec 04, 2011 2:49

You can write the code that you wish to optimize in C and then have the compiler create the optimized assembly code.
Sannaj
Posts: 27
Joined: Dec 19, 2010 16:39

Postby Sannaj » Dec 04, 2011 17:15

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.
TJF
Posts: 3604
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Postby TJF » Dec 04, 2011 18:34

Sannaj wrote:Step 2 is often unnecessary, since there are lots of cases when there is written an value to it by the code, ...

You can omit this step by using code like
    DIM AS INTEGER value = ANY
Sannaj
Posts: 27
Joined: Dec 19, 2010 16:39

Postby Sannaj » Dec 05, 2011 18:29

That's true. But it's still a possibility to optimise the compiler by distinguishing between [= 0] and [= any] automatically.
Richard
Posts: 3047
Joined: Jan 15, 2007 20:44
Location: Australia

Postby Richard » Dec 05, 2011 20:59

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.

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 6 guests