linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* r13 is non-volatile?
@ 2005-09-08 16:28 Kumar Gala
  2005-09-08 17:01 ` Segher Boessenkool
  0 siblings, 1 reply; 5+ messages in thread
From: Kumar Gala @ 2005-09-08 16:28 UTC (permalink / raw)
  To: linuxppc-dev list, ppc64-dev

Was looking at merging some code between ppc32 & ppc64 and noticed  
that in ppc32 we consider r13 to be part of the non-volatile register  
set.  Is this really correct?

r13 is suppose to be sdata pointer in ppc32 and system thread id in  
ppc64.  So I'm wondering should we really be considering it NV on ppc32?


PPC32:

#define SAVE_NVGPRS(base)       SAVE_GPR(13, base); SAVE_8GPRS(14,  
base); \
                                 SAVE_10GPRS(22, base)
#define REST_NVGPRS(base)       REST_GPR(13, base); REST_8GPRS(14,  
base); \
                                 REST_10GPRS(22, base)

PPC64:
#define SAVE_NVGPRS(base)       SAVE_8GPRS(14, base); SAVE_10GPRS(22,  
base)
#define REST_NVGPRS(base)       REST_8GPRS(14, base); REST_10GPRS(22,  
base)

- kumar

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: r13 is non-volatile?
  2005-09-08 16:28 r13 is non-volatile? Kumar Gala
@ 2005-09-08 17:01 ` Segher Boessenkool
  2005-09-08 19:30   ` linas
  0 siblings, 1 reply; 5+ messages in thread
From: Segher Boessenkool @ 2005-09-08 17:01 UTC (permalink / raw)
  To: Kumar Gala; +Cc: ppc64-dev, linuxppc-dev list

> Was looking at merging some code between ppc32 & ppc64 and noticed 
> that in ppc32 we consider r13 to be part of the non-volatile register 
> set.  Is this really correct?

I believe so, yes.

> r13 is suppose to be sdata pointer in ppc32

sdata pointer is non-volatile by definition...

> and system thread id in ppc64.

The 64-bit kernel uses GPR13 as the PACA pointer, so it handles
it specially -- it treats the userland values of the register
as non-volatile, though.

> So I'm wondering should we really be considering it NV on ppc32?

Yeah.  I'm sure there is some way to make the macro's identical
between 32- and 64-bit, though.


Segher

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: r13 is non-volatile?
  2005-09-08 17:01 ` Segher Boessenkool
@ 2005-09-08 19:30   ` linas
  2005-09-08 21:53     ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 5+ messages in thread
From: linas @ 2005-09-08 19:30 UTC (permalink / raw)
  To: Segher Boessenkool; +Cc: ppc64-dev, linuxppc-dev list

On Thu, Sep 08, 2005 at 07:01:18PM +0200, Segher Boessenkool was heard to remark:
> >Was looking at merging some code between ppc32 & ppc64 and noticed 
> >that in ppc32 we consider r13 to be part of the non-volatile register 
> >set.  Is this really correct?
> 
> >r13 is suppose to be sdata pointer in ppc32
> 
> sdata pointer is non-volatile by definition...
> 
> >and system thread id in ppc64.
> 
> The 64-bit kernel uses GPR13 as the PACA pointer, so it handles
> it specially 

There's a different value in R13 depending on which cpu you're on,
so one mustn't save R13 on one CPU and attempt to restore it on
another.

Maybe, for ppc32, you can pretend that r13 "is like a paca"? So
that instead of saving/restoring r13 like this, you could set it up
at the same time/instead of setting up the paca r13?

--linas

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: r13 is non-volatile?
  2005-09-08 19:30   ` linas
@ 2005-09-08 21:53     ` Benjamin Herrenschmidt
  2005-09-09  1:30       ` Kumar Gala
  0 siblings, 1 reply; 5+ messages in thread
From: Benjamin Herrenschmidt @ 2005-09-08 21:53 UTC (permalink / raw)
  To: linas; +Cc: ppc64-dev, linuxppc-dev list


> There's a different value in R13 depending on which cpu you're on,
> so one mustn't save R13 on one CPU and attempt to restore it on
> another.
> 
> Maybe, for ppc32, you can pretend that r13 "is like a paca"? So
> that instead of saving/restoring r13 like this, you could set it up
> at the same time/instead of setting up the paca r13?

ppc32 uses r2 for that, it contains "current".

I don't think we need to bother merging those low level CPU specific
things. We need to have a cpu32 and a cpu64 subdirs in there for things
like these, memory management, etc... imho.

Ben.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: r13 is non-volatile?
  2005-09-08 21:53     ` Benjamin Herrenschmidt
@ 2005-09-09  1:30       ` Kumar Gala
  0 siblings, 0 replies; 5+ messages in thread
From: Kumar Gala @ 2005-09-09  1:30 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: ppc64-dev, linas, linuxppc-dev list


On Sep 8, 2005, at 4:53 PM, Benjamin Herrenschmidt wrote:

>
>
>> There's a different value in R13 depending on which cpu you're on,
>> so one mustn't save R13 on one CPU and attempt to restore it on
>> another.
>>
>> Maybe, for ppc32, you can pretend that r13 "is like a paca"? So
>> that instead of saving/restoring r13 like this, you could set it up
>> at the same time/instead of setting up the paca r13?
>>
>
> ppc32 uses r2 for that, it contains "current".
>
> I don't think we need to bother merging those low level CPU specific
> things. We need to have a cpu32 and a cpu64 subdirs in there for  
> things
> like these, memory management, etc... imho.

My intent is to see if we can make a change so that there isn't an  
ifdef.

- kumar

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2005-09-09  1:30 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-09-08 16:28 r13 is non-volatile? Kumar Gala
2005-09-08 17:01 ` Segher Boessenkool
2005-09-08 19:30   ` linas
2005-09-08 21:53     ` Benjamin Herrenschmidt
2005-09-09  1:30       ` Kumar Gala

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).