However, looking at that instruction, it doesn't make any sense to
me. I don't see where R9 came from, and it looks like it actually
contains an address at the upper end of the user address space
(probably in the shared libraries?).
High bits 01 put it in P1 space, which is normally used for the stack
and not much else - I think shared libraries and the like are normally
mapped into P0 space, which is 0x0000000 through 0x3fffffff.
But, looking at the 4.0.1 code, I agree: I can't see where r9/r10 come
from. Nor do I see any point in stuffing the value, whatever it is, in
r0/r1; the code following the movd calls fltext_De, which saves and
restores r0 and r1 (via its entry mask), then calls getval_dfloat,
whose first instruction destroys r0/r1. So that movd looks useless on
both the input and output sides, and I'm surprised it's taken this long
for something to happen to have a reserved operand in r9 when it runs.