**********
* Using the predicate model, surround the logical test with brackets as the first item on the line:
*****
    [llTest] .??. someCodeGoesHere()        && Only executed if llTest is true

Somebody on another forum posted the message:
"What is more needed are:

    EXIT IF/WHEN lCondition
    LOOP IF/WHEN lCondition

That is the purpose of the predicate. For example:

    [lCondition] .??.  EXIT
    [lCondition] .??.  LOOP

These can be read as:
"If lCondition is true, then execute the EXIT command. If lCondition is flase, then do not execute it."
"If lCondition is true, then execute the LOOP command. If lCondition is false, then do not execute it."

Predication is a term used in computer science to determine if a particular command should be executed. The ARM CPU has an instruction set that allows predication on almost every instruction. The purpose of which is to prevent the need for (at the CPU level) expensive GOTO operations, which must invalidate, and then refill the CPU machine code instruction pipeline with data. While that only takes a few billionths of a second, the average computer program requires a jump every six or so instructions, resulting in a lot of unnecessary slowdown if it's constantly dumping and re-filling the instruction pipeline for simple code blocks like:

IF lCondition
    k = doSomething(i)
ENDIF

That would compile down into assembly as:

01:    CMP   lCondition,1    && "Compare lCondition to 1"
02:    JNZ   after           && "If they are not equal, skip the next instruction"
03:    MOV   EDX,variable_i  && Part 1 of 2 of the "(i)" part of the "k = doSomething(i)" command
04:    PUSH  EDX             && Part 2 of 2 of the"(i)" part of the "k = doSomething(i)" command 
05:    CALL  doSomething     && The "doSomething()" part of the "k = doSomething(i)" command   
06:    MOV   variable_k,EAX  && Store the result "k =" part of the expression
07:after:
08:    * Control would continue here

On line 02, the CPU would use "branch prediction" algorithms to determine if it is more likely the branch would be taken or not taken. If it "guesses" wrong, then the entire instruction pipeline must be invalidated, emptied, and re-loaded with the proper destination set of instructions, either beginning at line 03, or line 08.

With predication, that flow is reduced to something like this:

01:    CMP   lCondition,1    && "Compare lCondition to 1"
02:[Z] MOV   EDX,variable_i  && If ZERO? (meaning if they were equal), Part 1 of 2 of the "(i)" part of the "k = doSomething(i)" command
03:[Z] PUSH  EDX             && If ZERO? (meaning if they were equal), Part 2 of 2 of the"(i)" part of the "k = doSomething(i)" command 
04:[Z] CALL  doSomething     && If ZERO? (meaning if they were equal), The "doSomething()" part of the "k = doSomething(i)" command   
05:[Z] MOV   variable_k,EAX  && If ZERO? (meaning if they were equal), Store the result "k =" part of the expression
06:after:
07:    * Control would continue here

Whereas in this case it ALWAYS executes the instructions 02,03,04,05, the result is that if the ZERO? flag is not set, it doesn't actually do anything so it's very fast. It is faster than skipping around those instructions because the instruction pipeline can be fully maintained without the requirement of refilling it, as this refilling operation is expensive in terms of clock cycles lost to fetch the new memory location, and begin decoding all of the parts of the instruction (as modern CPU pipelines are typically 10 or more steps to execute each machine opcode instruction).