Page 3 of 3

Re: [NOT] Optimizing compiler

Posted: Fri Mar 12, 2021 6:21 pm
by useful
https://sol.gfxile.net/soloud/soloud_20 ... troduction
"The engine has been designed to make simple things easy, while not making harder things impossible."

When I read that, I immediately thought that engine in that sentence could easily be replaced by pure and spider basic-s

Re: [NOT] Optimizing compiler

Posted: Fri Mar 12, 2021 7:00 pm
by Tenaja
chi wrote:
Everything wrote:Is it possible to do something else in the field of code optimization?
You could try pbOptimizer, although there aren't many ASM optimizations yet (like removing PUSH/POP). Maybe I'll add them later?!
Yes, THAT!
I will share my call tree analyzer when I get a chance. (Don't hold your breath... Don't get a lot of time on my PC that isn't work.) This will help to eliminate unused procs, but it's not set up to account for those called by pointer.

I would also suggest a local var initializing analyzer... If you declare a local variable with an assignment, pb clears it anyway. Since I can't be the only one who refused to rely on that --partially due to habit, but partially not wanting to lose the habit--(and, often locals are set to non-zero), eliminating the redundant "set all locals to zero" might be appreciated by anybody wanting improved performance.

Re: [NOT] Optimizing compiler

Posted: Fri Mar 12, 2021 8:28 pm
by chi
Tenaja wrote:I will share my call tree analyzer when I get a chance. (Don't hold your breath... Don't get a lot of time on my PC that isn't work.) This will help to eliminate unused procs, but it's not set up to account for those called by pointer.
This is already implemented under Settings/Create .pb/Remove Uncalled Procs. Edit: But it's not perfect... Proc calls inside an uncalled procedure will not remove the called proc (if also redundant), yet. It's on my to-do list ^^
Tenaja wrote:I would also suggest a local var initializing analyzer... If you declare a local variable with an assignment, pb clears it anyway. Since I can't be the only one who refused to rely on that --partially due to habit, but partially not wanting to lose the habit--(and, often locals are set to non-zero), eliminating the redundant "set all locals to zero" might be appreciated by anybody wanting improved performance.
Could you please post a short test code in the pbOptimizer thread showing exactly what you want and how my program should handle it? Much easier this way ;)


Other suggestions are welcome as well... (with code samples, please)

Re: [NOT] Optimizing compiler

Posted: Sat Mar 13, 2021 1:36 am
by Keya
a recent (March 2021) blog post by Fred suggests PB is getting rewritten to have a C backend instead of asm (im guessing gcc on Win/Mac/Linux), so that should in theory also open the gate to all the compiler optimisation options as well. I for one am super excited about this!

Re: [NOT] Optimizing compiler

Posted: Sat Mar 13, 2021 3:22 am
by Tenaja
chi wrote:
Tenaja wrote:I will share my call tree analyzer when I get a chance. (Don't hold your breath... Don't get a lot of time on my PC that isn't work.) This will help to eliminate unused procs, but it's not set up to account for those called by pointer.
This is already implemented under Settings/Create .pb/Remove Uncalled Procs. Edit: But it's not perfect... Proc calls inside an uncalled procedure will not remove the called proc (if also redundant), yet. It's on my to-do list ^^
Tenaja wrote:I would also suggest a local var initializing analyzer... If you declare a local variable with an assignment, pb clears it anyway. Since I can't be the only one who refused to rely on that --partially due to habit, but partially not wanting to lose the habit--(and, often locals are set to non-zero), eliminating the redundant "set all locals to zero" might be appreciated by anybody wanting improved performance.
Could you please post a short test code in the pbOptimizer thread showing exactly what you want and how my program should handle it? Much easier this way ;)


Other suggestions are welcome as well... (with code samples, please)
The dead code, as you said, doesn't remove dead code called b dead code. My call tree analyzer does. Maybe Fred will implement something like it in the new back end.

Having a C target backend will open a lot of doors. We'll be able to compile with gcc if we want a coffee break, or something faster for debug... And I wouldn't be surprised if that debug system isn't one of the hardest things for them to convert.

Re: [NOT] Optimizing compiler

Posted: Sat Mar 13, 2021 3:27 am
by Tenaja
Also, a C backend could make using C libraries as simple as an include...

Re: [NOT] Optimizing compiler

Posted: Sat Mar 13, 2021 1:49 pm
by skywalk
Or, inline C. 8)

Re: [NOT] Optimizing compiler

Posted: Sat Mar 13, 2021 2:02 pm
by Keya
inline C ... inline asm ... an optimising compiler ... the POWER!!!

Re: [NOT] Optimizing compiler

Posted: Sat Mar 13, 2021 3:36 pm
by chi
Very exciting news!