The constant goes in the destination
Thumb's and Rd, Rs is two-operand and destructive: it computes Rd &= Rs and throws the old Rd away. There is no immediate form at all — no and r0, #7 exists in the instruction set — so every mask has to be materialised in a register before the and can use it.
That leaves the compiler a choice about which register holds the mask and which holds the value. gcc 2.9's first preference is to put the constant in the destination — the register the result has to end up in anyway. Here is a function masking its second argument:
0 mov r0, #7
2 and r0, r1
4 bx lr
Two instructions. The mask goes straight into r0, which is where the return value has to end up anyway, and the value being masked is sitting untouched in r1. Nothing is in the way.
Now watch what happens when the value being masked is already in r0 because some earlier instruction put it there:
0 add r0, #1
2 mov r1, #63
4 and r0, r1
6 bx lr
The sum lives in r0 and the allocator is free to keep it there, so the mask goes to the scratch register r1 and the operands flip round to and r0, r1. Same C operation, mirrored instruction.
Notice also the contrast in that listing: add carries its constant inside the instruction (add r0, #1), while the mask needs a whole mov of its own. add, sub and cmp have 8-bit immediate forms; and, orr, eor and bic have none. Arithmetic constants and bitwise constants look nothing alike in Thumb.
The third case is the one in your target, and it is the most common of all. When the value being masked arrives as the first argument it is already in r0 — the register the constant wants — so the compiler evacuates it first. That opening mov rN, r0 is a decompiler's tell: it says the thing being masked came in as argument one.
Your task
Write func_080ce890 to reproduce the target assembly.