Disassembled ASM problem.

[Karlos]

Thats quite strange.

Assuming the code entry is at LAB_0206, the compare operation at LAB_0207 would seem to be entirely wasted, since the cc fields will be set my the move.b that follows it.

The compare also seems to take no part in the loop because the branch offsets skip past it. Actually, I am not sure they do. They jump to the address + 2, which assuming a byte based offset actually jumps into the immediate word data of the instruction (the #$528B) - which is your addq #1, a3.

So the effects are that it harmlessly eliminates the effect of the addition operation on initial loop entry, since it is interpreted as a compare (which simply does nothing useful of itself) and each successive iteration afterwards it is interpreted as the add quick.

Hence, I guess its simply a method of suppressing the add operation the first time through the loop as a form of optimisation in the flow in a do/while style construct.

[Karlos]

I think you replied whilst I was editing my post :-)

As optimisations go, its a bit pointless as at best it saves one unconditional branch on loop entry. It's most likely a space saving optimisation rather than a performance one.

[Karlos]

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?

Or even vice versa, if a C compiler is optimising for size ;-)

-edit-

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

[Karlos]

@Piru

As I said, in this instance its wasted as a speed optimisation, it affects the first iteration of the loop 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?

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

[Karlos]

All true, of course. I guess it's because I always see the loop unrolled in my mind that optimisations such as this appear virtually futile to me, other than for space saving ;-)

-edit-

Speaking of all things low down and dirty, did you solve my float to int problem yet? I need a non conditional branching way of handling the x=1.0 case and if anybody can solve that one it's you. Don't make me come and extinguish the sauna now.... :-D

-edit2-

Dang, I forgot, I posted that problem prior to the great thread massacre of 2004...