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

login
register
mail settings
Submitter Oleg Endo
Date Oct. 8, 2012, 10:05 p.m.
Message ID <1349733920.21984.52.camel@yam-132-YW-E178-FTW>
Download mbox | patch
Permalink /patch/190156/
State New
Headers show

Comments

Oleg Endo - Oct. 8, 2012, 10:05 p.m.
Hello,

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

Cheers,
Oleg
Kaz Kojima - Oct. 9, 2012, 9:30 a.m.
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
Gerald Pfeifer - Oct. 16, 2012, 10:45 p.m.
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
Oleg Endo - Oct. 16, 2012, 10:57 p.m.
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
Gerald Pfeifer - Jan. 3, 2013, 5:13 a.m.
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
Oleg Endo - Jan. 5, 2013, 2:19 p.m.
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

Patch

? www_4_8_sh_changes_3.patch
Index: htdocs/gcc-4.8/changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.43
diff -u -r1.43 changes.html
--- htdocs/gcc-4.8/changes.html	8 Oct 2012 19:22:43 -0000	1.43
+++ htdocs/gcc-4.8/changes.html	8 Oct 2012 22:01:06 -0000
@@ -377,6 +377,15 @@ 
     is now enabled and the option <code>-ffinite-math-only</code> implicitly
     sets <code>-mno-ieee</code>.</li>
 
+    <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.  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.
+    </li>
+
   </ul>
 
 <h3 id="sparc">SPARC</h3>