[WIP/RFC] MIPS registers overhaul

[Andrew Cagney]

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