Compiler flags

[jartzi]

Currently -O is used for optimize option.
Tried -O2 but something in main function gives compiler internal error. Not got enought info to find out where error occurs. -O2 uses set of compiler flags and noticed that -fexpensive-optimizations cause error. Added only working flags from -O2. Managed to get SW compiled after minor changes to inline asm log parts. Not tried yet but generated asm seems to be much more better for my eye.

If anyone have interested to try how much these faster execution.

CFLAGS = -fthread-jumps -fcaller-saves -fcrossjumping -falign-loops -falign-labels -falign-functions -falign-jumps \
-fcse-follow-jumps -fcse-skip-blocks -fdelete-null-pointer-checks -fgcse -fgcse-lm -foptimize-sibling-calls \
-freorder-blocks -freorder-functions -frerun-cse-after-loop -fsched-interblock -fsched-spec \
-fstrict-aliasing -g -Wall -Werror -Wsign-compare -Wshadow -O -fomit-frame-pointer -m68hcs12 -mshort \
-msoft-reg-count=5 -mauto-incdec -fsigned-char

[jartzi]

Because MS have so big functions does it have advance to use bigger SW register value than -msoft-reg-count=5? About 8-10?

[jsmcortina]

Beware of unexpected side effects. e.g. STACK_SOFT

James

[jartzi]

I noticed that there is outpc.looptime in main loop.
Is there any SW which parse and show these outpc values?

[Alfagta]

I noticed that there is outpc.looptime in main loop.
Is there any SW which parse and show these outpc values?

Hello,
you can use Tuner Studio to see what the actual looptime is.

[jartzi]

Yes there is gauge for MainLoop time.

[jsmcortina]

I tried those compiler flags and after the tweaks to inline ASM you mentioned it failed to build as the code is larger and doesn't fit in the allocation regions.
Be aware that larger code usually means slower code.

You mentioned "large functions" in this topic. I've done some timing in the past and the function calling overhead is huge. Don't even think about breaking the code down into pretty small functions as you'll burn up a huge number of clock cycles with no benefit to running the engine.

Your -O2 test exposes another issue. gcc support for S12 is a little fragile. I've done some tweaks inside gcc to support a few for the S12X extensions (for MS3) but generally it is a black art. Trying to understand and resolve ICEs can consume days with little result.

James

[jartzi]

Be aware that larger code usually means slower code.

No. seem that compiler unwraps code and use jumps to pass code faster. It takes more code memory.

You mentioned "large functions" in this topic. I've done some timing in the past and the function calling overhead is huge. Don't even think about breaking the code down into pretty small functions as you'll burn up a huge number of clock cycles with no benefit to running the engine.

Yes i understand this. My mention was not blame about use of big functions. Only think could use of more sw registers made it faster.

[jsmcortina]

Previously I have spent days or even weeks tweaking stuff in the build chain and compiler. In the end the actual result on looptime was usually a very disappointing zero change. I try to avoid getting sucked into stuff like that now.

The single biggest improvement to the toolchain was when I persuaded a colleague to write a fresh implementation of the 32bit divide in assembler. This had a large impact on speed. It is included in the gcc on the MSEXTRA tools site.

James

[jartzi]

The single biggest improvement to the toolchain was when I persuaded a colleague to write a fresh implementation of the 32bit divide in assembler. This had a large impact on speed. It is included in the gcc on the MSEXTRA tools site.

32bit arithmetic in 16bit processor is slow. Even 16bit divide takes 11 cycles to execute.