Re: Another illegal instruction awk problem

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> r9             0x7f538000       2136178688
>> r10            0x138    312

> The failing instruction was "movd %r9,%r0", which I think is moving
> the D-floating in R9/R10 to R0/R1.  [...]

I agree with Michael's analysis here: r9/r10 do indeed form a reserved
operand, and it looks weird.

> 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.

If there are regression tests that would give us decent assurance that
emodd still works, I'd try yanking the movd and see if it still passes.
(If not, ideally, I'd say someone should create them.  But since I'm
not volunteering to do the work, I'm not about to try to volunteer
anyone else to.)

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B