[ Atariscne.org - News ] GCC for asm Experts (and C/C++ Intermediates) - Part 1
This is a brain dump of what I have learned working with the GCC m68k backend, and maybe an attempt to convince someone else to try. This is the first of an unknown number of posts. No promises for how many there will be; I will continue as long as I have something to say and I find it fun.
I got my start with STOS Basic on an Atari 520STfm around 1990. Me and my classmate Tam formed T.O.Y.S. (Terror on Your ST) and I dubbed myself PeyloW. But in the scene, elite sceners wrote assembly; only lamers used STOS or GFA, every scroll text was clear about this. So we bought DevPac 2 and taught ourselves 68000 assembly, starting with snippets embedded in STOS and eventually graduating to full demo screens. The pattern that would follow me for decades was established early: high-level languages for tooling, assembly for anything that had to be fast. STOS gave way to PurePascal in the late '90s, but assembly remained the language that mattered — right through to the Falcon030 demo "Wait", released at EIL 2001.
My active participation in the scene waned, but I never lost sight of it. For years I stayed as an observer, following releases and discussions from the sidelines. Then around 2021 I had an itch, maybe a mid-life crisis: get back to the simpler machines (the kind a single person can keep entirely in their head) and realize a teenage dream of publishing a completed game. C and C++ had become my main languages through University and work, and modern cross-development tools meant I could use them for Atari too. Not just for tooling, but as the scaffolding of the entire project, dipping into assembly only for the bottlenecks. And as my friend AiO likes to joke: C is just a really powerful macro assembler.
GCC Is (No Longer) Written for Us
The m68k was one of GCC's first backends, present alongside VAX in the 1987 GCC-1.0 release. For a long time it was a first-class citizen. But the world moved on, and the backend fell into disrepair, barely in maintenance mode, with no one actively working on it.
To be fair, the great strides made in modern compiler optimization are what keep the m68k backend limping along. For most codebases the result is on par with yesteryear, even if it completely fails at many of the specifics. Even a 68060 fitted into a Falcon with a CT63 is ancient by modern CPU standards. The optimizations that GCC's middle-end applies (instruction scheduling, loop transformations, register heuristics and reordering) are tuned for modern highly parallel superscalar CPUs, and when they miss on m68k, they miss badly.
Take the inner loop of a simple memory copy (mikro will recognize this one), in C:
*dst++ = *src++;
*dst++ = *src++;
*dst++ = *src++;
*dst++ = *src++;
Any experienced m68k programmer would expect (a0)+ and (a1)+, post-increment addressing, the most natural idiom on our architecture. The compiler should be able to generate this just as-is — it is how the code reads. Here is what stock GCC-15.2 produces at -O2:
.L3:
move.l (%a0),(%a1) | plain indexed, no post-increment
move.l 4(%a0),4(%a1)
move.l 8(%a0),8(%a1)
lea (16,%a0),%a0 | pointer update separated from accesses
lea (16,%a1),%a1
move.l -4(%a0),-4(%a1) | negative offset — the lea moved too early
The perfectly fine inner loop gets butchered in the name of scheduling for superscalar execution. Instructions get reordered, pointer increments get separated from their memory accesses, and the fourth copy ends up using a negative offset because the lea was hoisted above it. The result is slower and larger than what GCC-2.95 would have produced, and not even close to what an elite scener would have written. For command-line tools and utilities this is tolerable. For realtime demos and games, it is not.
And Yet — GCC Can Work for Us
But there is light at the end of the tunnel.