Insertion Sort of uint16_t halfwords? - sorting

Question

This is the first code for sorting whole signed words (int32_t):
I tried to change it to sort uint16_t unsigned halfwords. I'm almost done the code but something is missing. The problem is the sort, the architecture is ARM (in ARM mode, not Thumb); this is what I have done until now:
sort: STMFD SP!,{R4-R6,LR}
MOV R2,#1 //for (unsigned i = 1;
L1: CMP R2,R1
BHS L4 // i < toSort.size();
MOV R3,R2 // for (unsigned j = i
L2: SUBS R3,R3,#1// - 1; --j)
BLO L3 // j != -1;
ADD R6,R0,R3,LSL #2
LDRH R4,[R6]
LDRH R5,[R6,#2]
CMP R5,R4 // if (toSort[j+1] < toSort[j])
STRHT R4,[R6,#2]
STRHT R5,[R6] // swap(toSort[j], toSort[j+1]);
BLT L2
L3: ADD R2,R2,#1// else break; ++i)
B L1
L4: LDMFD SP!,{R4-R6,PC}
void insertionSort(vector<int>& toSort)
{
for (int i = 1; i < toSort.size(); ++i)
for (int j = i - 1; j >= 0; --j)
if (toSort[j+1] < toSort[j])
swap(toSort[j], toSort[j+1]);
else
break;
} */ This is the code that should be in assembly

Answer 1

Based on the original, your changes look reasonable, except that you need to shift #1 instead of #2 in the ADD R6,R0,R3,LSL #2.  This is because the #2 is for 4 byte integers, #1 would be for 2 byte integers.  This is a shift amount and the shift count reflects the power of 2 by which you want to scale the index.  For 4 byte integers we want to multiply/scale by 4, which is 22, whereas for 2 byte integers we want to multiply/scale by 2, which is 21.  When shifting in binary, the number of bits to shift multiplies by that power of 2.
However, I find it very difficult to believe that the original insertion sort actually works.  (Did you test it independently of your modifications?)
In particular, as I have said, "the swap is happening before the condition test", and, further your instruction told you that the strh should be conditional, another way of describing the same problem.
So, that code is not following the insertion sort as described in comment.
The intent of the if-statement within the inner loop is to detect when insertion point has been reached, and immediately stop the inner loop.  Or else if the insertion point hasn't been reached, then swap elements and continue the inner loop.
That code is instead doing the following:
swap ( toSort[j], toSort[j+1 );
if ( toSort[j+1] >= toSort[j] )
break;
With that being at the end of the inner loop.
Or more specifically:
conditionCodes = toSort[j+1] < toSort[j];
swap ( toSort[j], toSort[j+1 );
if ( conditionCodes is less than )
continue;
break;
The effect of this is that when the proper stopping point is reached, it will stop, but will also have unwantedly swapped two elements.
You can stop that swap from happening in the last iteration, either by changing the flow of control so that those store instructions are not executed, or as #fuz says, on ARM you can make those store instructions themselves each conditional, which is probably what the original author intended, given how far apart the CMP and BLT are.  However, the conditional operation of those stores was lost somewhere along the way.