SNK were the gods of the 68000. I still remember back in the day getting a bug report on my 68000 emulator:

When playing King of Fighters, the time counter would go down to 0 and then wrap around to 99, effectively preventing the round from ending.

Eventually I tracked it down to the behavior of SBCD (Subtract Binary Coded Decimal): Internally, the chip actually does update the overflow flag reliably (it's marked as undefined in the docs). SNK was checking the V flag and ending the round when it got set.

https://github.com/kstenerud/Musashi/blob/master/m68k_in.c#L...

SBCD was an old throwback instruction that was hardly used anymore, and the register variant took 6 cycles to complete (vs 4 for binary subtraction).

HOWEVER... For displaying the timer counter on-screen, they saved a ton of cycles with this scheme because extracting the digits from a BCD value is a simple shift by 4 bits (6 cycles) rather than a VERY expensive divide (140 cycles).

Interestingly, gcc-amigaos-gcc 6.5 uses dbra without having to jump through any of those contortions, as long as the optimisation level is set to at least -O1:

  _clear_screen:
        move.w #28672,3932160
        move.w #1,3932164
        move.l #3932162,a0
        move.w #-13570,d1
        move.w #1279,d0
  .L2:
        move.w d1,(a0)
        dbra d0,.L2
        rts

> Note how gcc is smart enough to detect that the expression ((0xc<<12) | 0xafe) is constant, so it can skip shifts and bitwise assembly operations and just emit the resulting immediate value at line 14. The same goes for the loop condition, gcc emits constant 1280 at line 10 in place of the multiplication 40x32. A classic compiler optimization called constant folding, but nice nonetheless.

This is actually required rather than an optimisation for any C compiler, from early on, as C semantically allows constant expressions rather than just constants to be used for statically allocated sizes, etc. While the 'optimisation' is not guaranteed you'll see even on -O0 the constant was evaluated at compile-time, as it's harder to not fold constant expressions sometimes than it is to just always fold them for the already required constant expression features.

Significant further gains are possible by simply unrolling the loop eight or 16 times to lower the overhead of the DBF per word written

The step with declaring hw registers in assembly reminds me how assignment of value to pointer is IIRC at best implementation defined, and at worst UB, and playing around with volatile saves you not from zealous optimizer.

Arguably every hardware register should be declared that way as a symbol

You can optimize further by unrolling the loop. For example:

  .L2:
        move.w d1,(a0)
        move.w d1,(a0)
        move.w d1,(a0)
        move.w d1,(a0)
        dbra d0,.L2
        rts

This is cool, but at that point, why write it in C at all? Why not just hand-roll some assembler? It's targeted at a specific platform anyway.

With Assembly.