Can someone help me understand cache conscience radix sort? (excerpt from journal article attached)
The naming in the pseudo-code seems to be making things more confusing than they need to be, and it also seems to be glossing over some detail, but here's what I think is going on. 

Let's just jump right in on a small example.
Suppose we have a data set, the integers 0-7 in binary:
$000, 001, 010, 011, 100, 101, 110, 111$. But obviously they're not necessarily given to you in sorted order. Let's say the input is actually:
$110, 101, 000, 010, 100, 111, 001, 011$. 

If all this data fits in the cache, then you just run normal radix sort. That's the first branch of the if statement. For illustration, lets say that the cache can only hold two elements. Therefore, we end up in the else branch. The "reverse sorting" step splits the input into two sub-buckets based on the most significant bit. 
So we get two buckets:

$1: (10, 01, 00, 11)$ and $0: (00, 10, 01, 11)$. We recursively call our function on each of these smaller buckets. Since they are smaller, they might now fit inside the cache, and we could run normal radix sort. 

So now we're in the recursive call on the first sub-bucket. The input is 
$1:(10, 01, 00, 11)$. However, our cache size is only 2. Therefore we move into the else branch again. We split the input into
$11:(0,1)$ and $10:(1, 0)$. and call the function recursively. Now finally on each of these recursive calls, the input is small enough to fit in the cache, and we run normal radix sort. 

The other recursive calls function similarly.
Their pseudo-code seems to be missing how the partitions are pieced back together in a cache conscious way. Maybe this is obvious or covered elsewhere in the paper.