[wwwdocs] SH 4.8 changes - document thread pointer built-ins

Hello,

This documents the new thread pointer built-ins in the SH www changes
for 4.8.
OK?

Cheers,
Oleg

Oleg Endo <oleg.endo@t-online.de> wrote:
> This documents the new thread pointer built-ins in the SH www changes
> for 4.8.
> OK?

Looks OK to me.

Regards,
	kaz

On Tue, 9 Oct 2012, Oleg Endo wrote:
> This documents the new thread pointer built-ins in the SH www changes
> for 4.8.

Thanks, Oleg.

I've got one change and one question:

+    <li>Added support for the built-in functions
+    <code>__builtin_thread_pointer</code> and
+    <code>__builtin_set_thread_pointer</code>.  This assumes that
+    <code>GBR</code> is used to hold the thread pointer of the current thread,
+    which has been the case since a while already. 

"since a while" -> "for a while", and I made that change.

That said, why is this important, and is there a fixed date or version?

+    Memory loads and stores
+    relative to the address returned by <code>__builtin_thread_pointer</code>
+    will now also utilize <code>GBR</code> based displacement address modes.

Why do these _now_ utilize these address modes, when per the above
__builtin_thread_pointer was just added?  This last sentence implies
a change when there does not seem to be one?

Gerald

On Wed, 2012-10-17 at 00:45 +0200, Gerald Pfeifer wrote:
> On Tue, 9 Oct 2012, Oleg Endo wrote:
> > This documents the new thread pointer built-ins in the SH www changes
> > for 4.8.
> 
> Thanks, Oleg.
> 
> I've got one change and one question:
> 
> +    <li>Added support for the built-in functions
> +    <code>__builtin_thread_pointer</code> and
> +    <code>__builtin_set_thread_pointer</code>.  This assumes that
> +    <code>GBR</code> is used to hold the thread pointer of the current thread,
> +    which has been the case since a while already. 
> 
> "since a while" -> "for a while", and I made that change.
> That said, why is this important, and is there a fixed date or version?

It might be important for some embedded systems software that does not
use the GBR for storing the thread pointer, but for something else (like
a pointer to some global table of frequently used stuff or something
like that).  I just thought it might be better to mention this.  But
you're right, the last "for a while" part sounds strange, and should
probably just be removed, reducing it to "This assumes that
<code>GBR</code> is used to hold the thread pointer of the current
thread."

> 
> +    Memory loads and stores
> +    relative to the address returned by <code>__builtin_thread_pointer</code>
> +    will now also utilize <code>GBR</code> based displacement address modes.
> 
> Why do these _now_ utilize these address modes, when per the above
> __builtin_thread_pointer was just added?  This last sentence implies
> a change when there does not seem to be one?

Because before GCC did not utilize GBR addressing modes on SH at all.
Now it can do that, if the base address is obtained via
__builtin_thread_pointer.  Does that make sense? :)

Cheers,
Oleg

Hi Oleg,

On Wed, 17 Oct 2012, Oleg Endo wrote:
>> +    <li>Added support for the built-in functions
>> +    <code>__builtin_thread_pointer</code> and
>> +    <code>__builtin_set_thread_pointer</code>.  This assumes that
>> +    <code>GBR</code> is used to hold the thread pointer of the current thread,
>> +    which has been the case since a while already. 
>> 
>> "since a while" -> "for a while", and I made that change.
>> That said, why is this important, and is there a fixed date or version?
> It might be important for some embedded systems software that does not
> use the GBR for storing the thread pointer, but for something else (like
> a pointer to some global table of frequently used stuff or something
> like that).  I just thought it might be better to mention this.  But
> you're right, the last "for a while" part sounds strange, and should
> probably just be removed, reducing it to "This assumes that
> <code>GBR</code> is used to hold the thread pointer of the current
> thread."

That sounds good.  I noticed this has not been changed yet, so I
assume you were probably waiting for my response?  Will you be
making this change?

>> +    Memory loads and stores
>> +    relative to the address returned by <code>__builtin_thread_pointer</code>
>> +    will now also utilize <code>GBR</code> based displacement address modes.
>> 
>> Why do these _now_ utilize these address modes, when per the above
>> __builtin_thread_pointer was just added?  This last sentence implies
>> a change when there does not seem to be one?
> Because before GCC did not utilize GBR addressing modes on SH at all.
> Now it can do that, if the base address is obtained via
> __builtin_thread_pointer.  Does that make sense? :)

Yep, it does. :-)  Thanks for the explanation.

Gerald

Hi,

On Wed, 2013-01-02 at 19:13 -1000, Gerald Pfeifer wrote:
> Hi Oleg,
> 
> On Wed, 17 Oct 2012, Oleg Endo wrote:
> >> +    <li>Added support for the built-in functions
> >> +    <code>__builtin_thread_pointer</code> and
> >> +    <code>__builtin_set_thread_pointer</code>.  This assumes that
> >> +    <code>GBR</code> is used to hold the thread pointer of the current thread,
> >> +    which has been the case since a while already. 
> >> 
> >> "since a while" -> "for a while", and I made that change.
> >> That said, why is this important, and is there a fixed date or version?
> > It might be important for some embedded systems software that does not
> > use the GBR for storing the thread pointer, but for something else (like
> > a pointer to some global table of frequently used stuff or something
> > like that).  I just thought it might be better to mention this.  But
> > you're right, the last "for a while" part sounds strange, and should
> > probably just be removed, reducing it to "This assumes that
> > <code>GBR</code> is used to hold the thread pointer of the current
> > thread."
> 
> That sounds good.  I noticed this has not been changed yet, so I
> assume you were probably waiting for my response?  Will you be
> making this change?

I also assume I was waiting for your response ;)
(it's been a while, can't remember exactly).

I'll send a patch with the change.  Thanks for reminding me.

Cheers,
Oleg