Author |
Message |
- Joined: 09 Aug 2021
- Posts: 140
|
SDCC: best practices for designing the game in C
Posted: Wed Apr 17, 2024 11:48 am Last edited by toxa on Mon May 06, 2024 7:14 pm; edited 1 time in total
|
[del]
|
|
|
- Joined: 05 Sep 2013
- Posts: 3859
- Location: Stockholm, Sweden
|
Posted: Wed Apr 17, 2024 1:54 pm
|
interesting list, I might add a few (minor) info
- favor 8 bit variables/constants over 16 bit (or larger!) ones
- unsigned are faster than signed
- use == , != , < , >= wherever possible, as <= and > are slower
when needing to if/else if/else among = or < or > do this:
if (a==SOMEVAL) {
// code to run when EQUAL
} else if (a<SOMEVAL) {
// code to run when LESS THAN
} else {
// code to run when MORE THAN
}
(if the a<SOMEVAL case is the more frequent outcome you can put that first and leave the a==SOMEVAL as second)
|
|
|
- Joined: 19 Oct 2023
- Posts: 162
|
Posted: Wed Apr 17, 2024 3:18 pm
|
Thanks for making this!
What about bitshift rather than multplication/division?
I've read in various places the compiler will optimise this itself in certain circumstances but haven't actually checked, I just do bitshift whenever I can.
|
|
|
- Joined: 09 Aug 2021
- Posts: 140
|
Posted: Wed Apr 17, 2024 3:36 pm Last edited by toxa on Mon May 06, 2024 7:14 pm; edited 1 time in total
|
[del]
|
|
|
- Joined: 05 Sep 2013
- Posts: 3859
- Location: Stockholm, Sweden
|
Posted: Wed Apr 17, 2024 4:36 pm
|
badcomputer wrote What about bitshift rather than multplication/division?
as toxa said, multiplications/divisions will likely be automatically optimized as long as it's by/divided by a constant so if you write
a=b*4;
it's fine - but if you instead write
a=b*c;
even if c is 4, there won't be any optimization.
(it might have been obvious but once I had a similar discussion with a game developer about the fact he was multiplying with a variable map_width whose value could be either 32 or 64 and was suggesting that the compiler would optimize that... no, it doesn't).
|
|
|
- Joined: 19 Oct 2023
- Posts: 162
|
Posted: Wed Apr 17, 2024 6:32 pm
|
Is it worth using --opt-code-speed with SDCC? Or any other compiler options that might help?
|
|
|
- Joined: 06 Mar 2022
- Posts: 689
- Location: London, UK
|
Posted: Wed Apr 17, 2024 6:49 pm
|
badcomputer wrote Is it worth using --opt-code-speed with SDCC? Or any other compiler options that might help?
I always turn that on.
I keep meaning to do the experiment of what differences it made. I thought it caused more inlining (including of functions) but Toxa said at some point that functions are never automatically inlined, so not sure.
|
|
|
- Joined: 09 Aug 2021
- Posts: 140
|
Posted: Wed Apr 17, 2024 7:06 pm Last edited by toxa on Mon May 06, 2024 7:15 pm; edited 1 time in total
|
[del]
|
|
|
- Joined: 29 Mar 2012
- Posts: 889
- Location: Spain
|
Posted: Thu Apr 18, 2024 7:44 am
|
toxa wrote badcomputer wrote Is it worth using --opt-code-speed with SDCC? Or any other compiler options that might help?
I never use that, --max-allocs-per-node with some large value produce better results.
I haven't tried this, any advice about which value to use?
|
|
|
- Joined: 09 Aug 2021
- Posts: 140
|
Posted: Thu Apr 18, 2024 8:01 am Last edited by toxa on Mon May 06, 2024 7:15 pm; edited 1 time in total
|
[del]
|
|
|
- Joined: 29 Mar 2012
- Posts: 889
- Location: Spain
|
Posted: Thu Apr 18, 2024 8:19 am
|
toxa wrote kusfo wrote I haven't tried this, any advice about which value to use?
50000 and above. but that may slow down the compiling process.
Thanks! I'll test it, I can have it enabled only for the release process
|
|
|
- Joined: 05 Sep 2013
- Posts: 3859
- Location: Stockholm, Sweden
|
Posted: Thu Apr 18, 2024 9:42 am
|
I compile SMSlib for release using
--max-allocs-per-node 100000
but it really takes *a lot* of time and it hardly is much different from what I would get without it. But I thought it's worth for a release build.
|
|
|
- Joined: 09 Aug 2021
- Posts: 140
|
Posted: Thu Apr 18, 2024 9:43 pm Last edited by toxa on Mon May 06, 2024 7:15 pm; edited 1 time in total
|
[del]
|
|
|
- Joined: 05 Sep 2013
- Posts: 3859
- Location: Stockholm, Sweden
|
Posted: Fri Apr 19, 2024 7:43 am
|
toxa wrote sverx wrote I compile SMSlib for release using
SMSlib has very little and very specific C code and thus not much opportunities to optimize anything
True, and that's why I said
>> it hardly is much different from what I would get without it
still, I don't get exactly the same output without it, since there are still parts which aren't written in inline asm.
|
|
|
- Joined: 07 Aug 2007
- Posts: 222
- Location: Yach, Germany
|
Posted: Today at 5:02 pm
|
willbritton wrote badcomputer wrote Is it worth using --opt-code-speed with SDCC? Or any other compiler options that might help?
I always turn that on.
I keep meaning to do the experiment of what differences it made. I thought it caused more inlining (including of functions) but Toxa said at some point that functions are never automatically inlined, so not sure.
It does mostly affect choices made in register allocation and code generation where there is a code size vs. code speed trade-off. The impact of this is quite a bit stronger in SDCC 4.4.0 vs. versions up to SDCC 4.3.0.
Essentially --opt-code-speed and --opt-code-size just change the optimization goal, not how much optimization is done.
SDCC currenlty does not have an inlining heuristic, so these do not affect inlining.
|
|
|