Short branch converted to NOP

[jman]

Hello,

I've enabled all compile warnings on DevPac and I see a couple of interesting things, for example this (meaningless) code:

main:
    moveq    #0,d0
    bra.s    .here
.here
    moveq    #1,d0
    rts
    
    end

triggers the warning mentioned in the subject: "short branch converted to NOP".

Inserting a NOP between the BRA and the local label solves. Or remove the branch.
The DevPac warning that manages this is "NULL branches to NOP - ON/OFF/WARN".

But what it is exactly that is bothering the assembler? Is it just a "style" suggestion?

thx

[Siggy999]

I don't think it's bothering it, more trying to do you a favor.

'Hey, you have this statement here you don't need.. I can just do nothing and it will be more efficient'

You're just 'branching' to the next instruction - if you insert the nop, you have thing to jump-over, something to branch to.

or the alternative: remove the statement that does nothing.

(I actually get this one come up on me from time to time as I have a habit of putting in a branch and a label when I'm working on something with a comment 'blah blah' goes here - so the branch is going to be eventually needed, I've just not coded that little bit - I've taken to doing a nop followed by the 'blah blah' comment...)

[Toni Wilen]

Instruction:

bra.s label
label:

does not exist!

It would have instruction opcode of 6000 (60 XX where XX = 8-bit jump offset) which is reserved for bra.w (two word instruction 6000 xxxx where xxxx = 16-bit offset)

Also 60FF = bra.l (three word instruction 60FF xxxx xxxx where xxxx xxxxx = 32-bit offset), 68020+ only. (Some cracktro or trainer used 60FF to cause address error, on 68020+ it jumped to some random memory instead..)

[jman]

Originally Posted by Toni Wilen

It would have instruction opcode of 6000 (60 XX where XX = 8-bit jump offset) which is reserved for bra.w (two word instruction 6000 xxxx where xxxx = 16-bit offset)

Also 60FF = bra.l (three word instruction 60FF xxxx xxxx where xxxx xxxxx = 32-bit offset), 68020+ only. (Some cracktro or trainer used 60FF to cause address error, on 68020+ it jumped to some random memory instead..)

Amazing! Thank you Toni.