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

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

[Oleg Endo]

[-- Attachment #1: Type: text/plain, Size: 105 bytes --]

Hello,

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

Cheers,
Oleg

[-- Attachment #2: www_4_8_sh_changes_3.patch --]
[-- Type: text/x-patch, Size: 1032 bytes --]

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

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

[Kaz Kojima]

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

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

[Gerald Pfeifer]

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

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

[Oleg Endo]

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

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

[Gerald Pfeifer]

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

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

[Oleg Endo]

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

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

[Oleg Endo]

[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]

On Sat, 2013-01-05 at 15:19 +0100, Oleg Endo wrote:
> 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
> 
> 

I have just committed the attached patch to fix the issue mentioned
above.

Cheers,
Oleg


[-- Attachment #2: www_4_8_sh_changes_4.patch --]
[-- Type: text/x-patch, Size: 1151 bytes --]

? www_4_8_sh_changes_4.patch
Index: htdocs/gcc-4.8/changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.88
diff -u -r1.88 changes.html
--- htdocs/gcc-4.8/changes.html	20 Jan 2013 13:41:25 -0000	1.88
+++ htdocs/gcc-4.8/changes.html	27 Jan 2013 13:42:23 -0000
@@ -671,10 +671,10 @@
     <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 for 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.
+    <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.
     </li>
 
   </ul>