The following two conditionals will cause the compiler to generate different branch conditions:
Both instruction sequences will execute correctly. What is expected is that if the condition (a==0) is true, then the call to "do_something_else" is not executed. This is the case with both sequences. However, the sequence on the left predicts that the branch will not be taken, causing the 80960CA to pre-fetch the instruction "b _do_something_else" although the expectation is that this instruction will be rarely, if ever, executed.
If there is code between the THEN condition curly braces, in this case "do_something();" as in the example on the right, the compiler selects a branch type which favors the THEN condition. In conjunction with the ".f" branch prediction, the 80960CA will pre-fetch the instruction "b _do_something" which is what we really wanted.
The behavior depicted on the left side becomes evident when the code contains tests such as one might do for exit status from a function call. For example, the code fragment:
int STATUS, funcA(), funcB();
STATUS=funcA();
if (!STATUS) { /* if funcA() exit status is 0, do nothing */ }
else
fprintf(stderr,"funcA failed\n");
funcB();
will be compiled similar to the left side example above, causing the 80960CA to pre-fetch the error message although the expectation is that funcA() would never fail.
In conclusion, the user who expects to make optimal use of 80960CA branch prediction, e.g. to minimize bus activity, must be very careful when writing if-then conditionals. Take into account the ".f" branch prediction which is always suffixed to the forward branch and the compiler's sensitivity to the structure of the conditional. It is recommended that the users compile their code to assembly by using the -S switch, examine the compiler generated code for if-then conditionals and then restructure the source as necessary to take advantage of the 80960CA branch prediction.
Legal Stuff © 1997 Intel Corporation