PeyloW of T.O.Y.S. have been busy lately by optimizing the GNU C Compiler (GCC) v15.2 to create faster code for 68000 processor.
The improvements include using proper dbra/dbf loops, auto inc/dec of address registers (you know, the stuff that is nice on 68k!).
PeyloW writes in an Atari-Forum post:
At a very high level there are 7 groups of changes made:
-
Cost Model - More accurate cost models, allowing gcc to chose better.
-
Register Allocation – Adopt LRA, and tune to prefer fewer registers.
-
Loop Optimization – Adopt new doloop hooks to enable more explicit use of dbra.
-
Memory Access Reordering – More of cleanup pass for other optimisations, try to ensure memory access is sequential.
-
Autoincrement Optimization – Which allows more auto increment to be used instead of indexed addressing.
-
16/32-bit Optimization – And merging of 2x word accesses into single long access. Also narrow mulu/muls operators to word size if operand sizes can be determined at compile time.
-
Various Smaller Optimizations – Grab bag of stuff. Single bit extraction bit btst/tas, and simple peephole optimizations.
While working on GCC, PeyloW also developed a separate tool to count 68000 cycles out of assembler sourcecode to easily check if the compiler changes actually improve stuff - but can certainly can be very useful for other purposes as well.
Both projects can be found on Github, see links below.
🔗 m68k GCC Build Scripts and Documentation
Comments
Thank you so very much for this work. A few questions:
1. What is the chances of these improvements getting merged back into mainline gcc? I'm just worried about these fixes getting frozen for one specific version of gcc.
2. How about 68030 and beyond? How well do these processors benefit from the improvements? From the description of the improvements it sounds like they should benefit a lot as well.
1. Chances of upstream merging are very low. I have no plans to drive that myself. As for future versions of gcc, it’s the same story as for -mfastcall and mint support. It never got upstreamed either, but there is a crew of dedicated folks who keep porting forward as new gcc version comes along. And the upstream m68k target rarely has any changes between major versions. So I'm not worried, that this can be carried forward as "clean" cherry-picks.
2. A bit of a mixed bag on 68020+. This whole adventure is driven by my own needs, and I target plain Atari STe. This may change if/when I decide to take out my old Falcon030 again. My goal is to at the very least not have 020+ regress, but any progressions are merely happy accidents ;). Generally, optimizations carry over quite well.
Currently, I'm working through the accidental regressions on plain 68000. Using dbra may, for example, its great in some cases, but for others, it causes more registers to be needed, and you get cascades of downstream effects. It is a tricky scale to balance just right, but fun :D.
And the CLI cycle Counter Tool is really Great - thanks a lot!
Yes, I understand it is tricky. Thanks for your work, it will benefit the community at large and it will also help me personally in my ongoing project.
Wrote a longer write-up for the bug over at Atari Forums; https://www.atari-forum.com/viewtopic.php?t=45908