Disassembled ASM problem.

[Piru]

The places that have this type of optimisation were possibly written in asm in the first instance. Those that don't are perhaps the result of C compilers?

Such code is commonly generated by C compilers because it's typically faster than branching, and often reduces code size too.

Would this count as a form of self modifying code? It's certianly a "self reinterpreting" code

This indeed can cause some problems with 68060's Branch Prediction cache. Specifically it can result in Access Error exception with Branch Prediction Exception bit set (BPE bit in FSLW). In such cases the exception handler needs to flush the branch cache before continuing.

NOTE: This isn't something coders need to worry about, unless if you're implementing your own OS or replacing the access error exception vector. :-)

[Piru]

As I said, in this instance its wasted as a speed optimisation, it affects the first interation only. Surely a size optimisation then - it would save 2 bytes overall compared to a bra.b into the loop body after the add instruction, right?

Yeah.. But in cases where two set of instructions are equally fast, if the other reduces to fewer memory/cache inst fetches, the smaller code is generally faster. This is highly academic though, as it much depends on the state of the cache, and the total size of the code being executed, aswell as the target CPU. Anyway, in essense size optimization that doesn't slow down execution can be considered speed optimization, too.

Given that on the 060 it may invoke an exception, it's hardly a speed optimisation anymore

Well, it was ok for 68020/68030 at least, possibly with 68040. But if the code is to be executed on 68060, it's obviously not recommended.