Difference between bne+ and bne-

[Bully@Wiiplaza]

I personally used bne- for most of my codes that needed that sort of branch. I´ve seen people using bne+, though. I´ve googled and didn´t find explanations. What´s the difference? It´s definitely not huge, but I don´t see why they would use + and - for no reason. :o

[megazig]

it's called branch prediction and is part of the BO field in the opcode. if it will likely take the route make it a bne+, if it won't make it a bne-.
usually the processors own branch prediction is good enough to judge it with just a bne.

[Bully@Wiiplaza]

Ah, okay. I´ll just use bne forever and it will always be fine, I guess.

[wiiztec]

bne+ branches back to a previous asm line, it's used in loops

[megazig]

dead wrong

[dcx2]

Branch "hint" might be a better term than branch prediction.  The CPU will take the hint into consideration when deciding what instructions to speculatively execute.  This improves performance because if the CPU speculates incorrectly, it will have to flush the pipeline (a "stall").  The penalty for a stall isn't *that* bad in general, but if you really cared about every last ounce of performance, you'd want to set the branch hint accordingly.

wiiztec is not dead wrong, only technically wrong.  The vast, vast majority of the time, + is a loop that's going to a previous line and - is skipping forward over something.  It is not strictly required that + is branching backwards, but in the thousands of branches I have seen, I cannot recall any game compiled code where this was not the case.

There's a good reason for this, too.  Loops are usually executed a lot, and so it makes sense to simply assume that a loop branch will always be taken.  In almost all cases, a branch backwards involves a loop.

I'm pretty sure that a "bne" with no hint would be the same as "bne-".

[megazig]

please see F.5.4 of 6xx_pem.pdf titled Branch Prediction
bne is the same as bne- except that the assembler decides whether it will append the y bit. bne without assumptions by the compiler means that it will be -

the reason you see + for jumping up lower in memory is due to case 1. this is not mandatory of the asm though. so to say that + means it jumps to lower memory is wrong. correlation and causation and all

[dcx2]

Well, the "y" bit of the BO field can either be 1 or 0.  If it's 0, then the CPU interprets the instruction is a bne-.  If it's 1, it's a bne+.  From the CPU's perspective (or a disassembler's perspective), there is no "bne", it's just bne-, because they both have identical machine code bits.

I understand that you're talking about what you feed to the assembler that's generating your machine code.  For typical Wii hackers using e.g. ASMWiiRD or PyiiASMH, providing just "bne" will result in bne- (i.e. the "y" bit is 0)

It is not strictly *required* for branches that jump backwards to use the + hint.  You could easily take a bne- and hack it to be bne+ and it still behaves as expected.  But to say wiiztec is "dead wrong" implies that you should easily be able to find game compiled code using a conditional branch and a + hint that branches forward.  In all of the game compiled code I have ever looked at, I have never seen any exception to wiiztec's comment.

[γRB]

"If the assembly language programmer knows the likely outcome of a conditional branch, a suffix can be added to the mnemonic that indicates which way the branch should be predicted to go: a ‘+’ instructs the processor to predict that the branch will be taken, while a ‘-’ instructs it to predict that the branch will not be taken."
Use the jbsr pseudo instruction when you may not be able to reach the target of a branch and link instruction with a bl instruction. The jbsr instruction uses a sequence of code called a long branch stub which will always be able to reach the target.
https://developer.apple.com/library/mac/#documentation/DeveloperTools/Reference/Assembler/050-PowerPC_Addressing_Modes_and_Assembler_Instructions/ppc_instructions.html#//apple_ref/doc/uid/TP30000824-TPXREF101

[dcx2]

That is interesting.

However, there's no reason to ever use jbsr on a Wii.  All PowerPC code on the Wii executes in MEM1, which is only 24 MB.  However, the bl instruction (more properly, a branch with LK=1) has a 24-bit LI field, which allows it to take a relative branch to any instruction within 32 MB of the current instruction (LI is effectively 26 bits with the last two set to 0, which gives 64 MB range, but we split this in half because it is a signed field which can branch forward or backward).  So the worst case bl on a Wii - an instruction at 80000000 which tries to bl to 817FFFFC - can be executed without a long branch stub.

FWIW, instead of jbsr most hackers would probably just insert the ASM directly.  lis/ori the address into r12, mtctr r12, bctr.

[γRB]

Ho, I am aware how the DMA is divided in.. And honestly when I had to branch a few things, as someone suggested me to do, I used Unconditioned and Conditioned branches, for example in an easy ASM if code:
lis r0,0x8000
ori r0,r0,0x1234 //We loaded the timer at 0x80001234
li r0,0 //We set the timer to 0, so we can start the counter
cmpwi r0,0xXX //Where XX=Value of the timer (Hex), 0bXX (binary) or xx (dec), if its equal to 0xXX, then bne- END
bne- END
END:
//insert your custom value here

For that^ I'd use a b aswell if I had to edit it..