Hi Maciej, > The operation is only defined for bits 63:0 AFAICS. IIUC bits 127:64 > remain unchanged (which is why I think that at the initial stage of R5900 > support they have to be explicitly set to a fixed value on a context > switch, to prevent leaking information), but I have no means to verify it. > > In the interim to fix the value of bits 127:64 while keeping disruption > to existing code at the minimum you could AFAICT use a sequence like: > > pcpyld $1, $0, $1 > pcpyld $2, $0, $2 > # ... > pcpyld $31, $0, $31 > > in RESTORE_SOME, preferably via an auxiliary macro. Once we have switched > to saving/restoring full 128-bit registers, possibly with SQ/LQ, we can > remove this temporary measure. Sounds reasonable! > This would verify whether the original contents of $17 were a properly > sign-extended 32-bit value. Although for predictable operation I would > advise to use: > > sll k1, $17, 0 > sw k1, PT_R17(sp) > lw k1, PT_R17(sp) > tne k1, $17, 12 > > or simply: > > sll k1, $17, 0 > tne k1, $17, 12 > sw $17, PT_R17(sp) There is a slight complication: the trap appears to be taken before the console is ready, hence nothing is displayed. Is there a practical way to postpone or recover from a trap? The issue becomes somewhat involved since the trap needs to save/restore registers for itself to recover, and so might evoke boundless recursion.
