Re: [WIP/RFC] MIPS registers overhaul

Andrew Cagney
2003-05-21T15:40:30Z

> At Tue, 20 May 2003 16:23:34 -0400, Andrew Cagney wrote:
>
>> When a 64 bit kernel goes to save/resume an o32 process, how does it do
>> it? Does it have a choice?
>
>
> it has limited choice.
>
>
>
>> For instance, do a 64 bit FP restore then clear the FR bit; the reverse;
>> some other variant; ...?
>
>
> So, if the process is running with FR=0, then the save/restore should
> ("must" i believe) be done with FR=0.
>
> When FR=0, there are two options as to how to do it:
>
> for (i = 0; i < 32; i++)
> move/store word from c1 reg $i (i.e., dmfc1/sdc1)
>
> OR:
>
> for (i = 0; i < 32; i += 2)
> move/store dword from c1 reg $i (i.e., dmfc1/sdc1)

That isn't quite the detail I was looking for. Does the code need to
look like:

save::
save FSR
if (FSR & FR)
save 32x32 FP
else
save 32x64 FP

restore::
restore FSR
if (FSR & FR)
restore 32x32 FP
else
restore 32x64 FP

that is, the FSR[FR] bit (wonder if I've got the names right) needs to
set/clear the FR bit before it even starts to consider saving/restoring
the other registers. The reverse operation:

save::
save FSR
make FP registers 64 bit
save 32x64 FP

restore::
// assume FSR[FR] set to 64 bit mode
restore 32x64 FP
restore FSR

operation not being valid.

Andrew

> (move to / load for the state restore, of course.)
>
> (of course, these will typically be written in assembly code, and
> "fully unrolled" -- the pseudo-C-code is to demonstrate the concept
> only.)
>
> either one is valid, though all implementations that I know of choose
> the latter because it's fewer instructions and almost certainly more
> efficient.
>
>
> the linux kernel presents that to o32 userland (o32 ptrace syscall) as
> an array of 32 32-bit values, but IIRC it's stored internally as (8
> byte reg, 8 byte pad) * 16.
>
>
>
> cgd
>
>