www.digitalmars.com         C & C++   DMDScript  

D.gnu - version statement problem in gdc

reply "John Colvin" <john.loughran.colvin gmail.com> writes:
void main() {
	version(D_InlineAsm_X86_64) {
                 pragma(msg,"x64");
         }
	else version(D_InlineAsm_X86) {
                 pragma(msg,"x86");
         }
	else {
               	pragma(msg,"None");
         }
}

dmd/ldc -m64: x64
gdc -m64/32 : None
Apr 07 2013
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Sunday, 7 April 2013 at 23:02:28 UTC, John Colvin wrote:
 void main() {
 	version(D_InlineAsm_X86_64) {
                 pragma(msg,"x64");
         }
 	else version(D_InlineAsm_X86) {
                 pragma(msg,"x86");
         }
 	else {
               	pragma(msg,"None");
         }
 }

 dmd/ldc -m64: x64
 gdc -m64/32 : None

Ah, I see D inline asm isn't supported in gdc. When I removed the version check from my code I got a massive slew of errors telling me so (one for every asm line, not one per asm block). What's stopping iasm in gdc, ldc appears to have no problem.
Apr 07 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-04-08 22:17, Iain Buclaw wrote:
 On 8 April 2013 17:55, John Colvin <john.loughran.colvin gmail.com

     So, overall, it's not gonna happen unless dmd changes its
     implementation of inline asm?



 Pretty much.  Though given that what you have changed is in rt folders,
 I think the intent is that each compiler maintains its own, so it
 wouldn't be difficult just to re-implement using extended assembler.

How does GCC implement its inline assembler. What's the difference compared to how DMD implements its own? -- /Jacob Carlborg
Apr 08 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-04-09 09:39, Johannes Pfau wrote:

 GCC compilers always generate target-specific asm first, then the
 target specific assembler (as) is called to assemble that to an object
 file. The difference is that gcc inline asm is identical to the native
 assembly so it's just passed through to the assembler.

Aha, I see. -- /Jacob Carlborg
Apr 09 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--e89a8f83ab13a3e43b04d9ce4d68
Content-Type: text/plain; charset=ISO-8859-1

On Apr 8, 2013 12:10 AM, "John Colvin" <john.loughran.colvin gmail.com>
wrote:
 On Sunday, 7 April 2013 at 23:02:28 UTC, John Colvin wrote:
 void main() {
         version(D_InlineAsm_X86_64) {
                 pragma(msg,"x64");
         }
         else version(D_InlineAsm_X86) {
                 pragma(msg,"x86");
         }
         else {
                 pragma(msg,"None");
         }
 }

 dmd/ldc -m64: x64
 gdc -m64/32 : None

Ah, I see D inline asm isn't supported in gdc. When I removed the version

every asm line, not one per asm block).
 What's stopping iasm in gdc, ldc appears to have no problem.

If only that logic held water... GDC actually provided the implementation of iasm to LDC. Reasons why it was yanked out. - one big ugly x86 special case. - depended on backend headers poisoned for use in the frontend. - frontend should not know or care about what arch it is targeting. - likewise, use of TARGET_ macros is tabooed in gcc frontends. - most iasm in druntime/phobos rely on dmd's non-standard calling convention. - it has been argued in the past that gdc should not define D_InlineAsm_X86 if it does not follow dmd's ABI. Could probably think of a few dozen more to throw at you. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --e89a8f83ab13a3e43b04d9ce4d68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p><br> On Apr 8, 2013 12:10 AM, &quot;John Colvin&quot; &lt;<a href=3D"mailto:john= .loughran.colvin gmail.com">john.loughran.colvin gmail.com</a>&gt; wrote:<b= r> &gt;<br> &gt; On Sunday, 7 April 2013 at 23:02:28 UTC, John Colvin wrote:<br> &gt;&gt;<br> &gt;&gt; void main() {<br> &gt;&gt; =A0 =A0 =A0 =A0 version(D_InlineAsm_X86_64) {<br> &gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pragma(msg,&quot;x64&quot;);<br> &gt;&gt; =A0 =A0 =A0 =A0 }<br> &gt;&gt; =A0 =A0 =A0 =A0 else version(D_InlineAsm_X86) {<br> &gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pragma(msg,&quot;x86&quot;);<br> &gt;&gt; =A0 =A0 =A0 =A0 }<br> &gt;&gt; =A0 =A0 =A0 =A0 else {<br> &gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pragma(msg,&quot;None&quot;);<br> &gt;&gt; =A0 =A0 =A0 =A0 }<br> &gt;&gt; }<br> &gt;&gt;<br> &gt;&gt; dmd/ldc -m64: x64<br> &gt;&gt; gdc -m64/32 : None<br> &gt;<br> &gt;<br> &gt; Ah, I see D inline asm isn&#39;t supported in gdc. When I removed the = version check from my code I got a massive slew of errors telling me so (on= e for every asm line, not one per asm block).<br> &gt;<br> &gt; What&#39;s stopping iasm in gdc, ldc appears to have no problem.</p> <p>If only that logic held water...</p> <p>GDC actually provided the implementation of iasm to LDC.=A0 Reasons why = it was yanked out. <br> - one big ugly x86 special case.<br> - depended on backend headers poisoned for use in the frontend. <br> - frontend should not know or care about what arch it is targeting.<br> - likewise, use of TARGET_ macros is tabooed in gcc frontends. <br> - most iasm in druntime/phobos rely on dmd&#39;s non-standard calling conve= ntion.<br> - it has been argued in the past that gdc should not define D_InlineAsm_X86= if it does not follow dmd&#39;s ABI.</p> <p>Could probably think of a few dozen more to throw at you. </p> <p>Regards<br> -- <br> Iain Buclaw</p> <p>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;;<br> </p> --e89a8f83ab13a3e43b04d9ce4d68--
Apr 07 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 8 April 2013 at 00:13:29 UTC, Iain Buclaw wrote:
 If only that logic held water...

 GDC actually provided the implementation of iasm to LDC.  
 Reasons why it
 was yanked out.
 - one big ugly x86 special case.

Fair enough, although I see no reason why Ds iasm shouldn't be extended to support other architectures in the future.
 - depended on backend headers poisoned for use in the frontend.

when you say poisoned, I presume you mean by the license?
 - frontend should not know or care about what arch it is 
 targeting.

what about all the other arch specific version statements? e.g. version(ARM)
 - most iasm in druntime/phobos rely on dmd's non-standard 
 calling convention.
 - it has been argued in the past that gdc should not define 
 D_InlineAsm_X86 if it does not follow dmd's ABI.

Is it a feasible idea to automatically convert dmds inline asm to gcc's extended inline asm? A bit of context: I've been updating the inline asm array ops code in druntime (e.g. a[] += b[];) and managing to outpace gdc's codegen by - in some cases - a factor of 5. I'm very surprised by this, but as far as I can tell I'm not making any mistakes with the benchmarking. This is with the latest gdc with gcc4.9 snapshot (-O3 -frelease -fno-bounds-check), compared with the latest ldc and dmd. If my work gets merged in to druntime*, it could leave a situation where gdc loses out. *some preliminary work can be seen here, although I have made some significant changes I haven't pushed yet: https://github.com/D-Programming-Language/druntime/pull/471
Apr 08 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7b676c0692bc8d04d9db18db
Content-Type: text/plain; charset=ISO-8859-1

On 8 April 2013 15:49, John Colvin <john.loughran.colvin gmail.com> wrote:

 On Monday, 8 April 2013 at 00:13:29 UTC, Iain Buclaw wrote:

 If only that logic held water...

 GDC actually provided the implementation of iasm to LDC.  Reasons why it
 was yanked out.
 - one big ugly x86 special case.

Fair enough, although I see no reason why Ds iasm shouldn't be extended to support other architectures in the future. - depended on backend headers poisoned for use in the frontend.

when you say poisoned, I presume you mean by the license? From system.h

/* Front ends should never have to include middle-end headers. Enforce this by poisoning the header double-include protection defines. */ #ifdef IN_GCC_FRONTEND #pragma GCC poison GCC_RTL_H GCC_EXCEPT_H GCC_EXPR_H #endif --- The implementation of IASM required access to rtl.h and expr.h - which is able to give you information about stack layout, etc.
  - frontend should not know or care about what arch it is targeting.

what about all the other arch specific version statements? e.g. version(ARM)

TARGET_OS_D_BUILTINS. If defined, these provide the frontend all version conditions without the frontend having a large portion of code #ifdef'ing all over the place.
  - most iasm in druntime/phobos rely on dmd's non-standard calling
 convention.
 - it has been argued in the past that gdc should not define
 D_InlineAsm_X86 if it does not follow dmd's ABI.

Is it a feasible idea to automatically convert dmds inline asm to gcc's extended inline asm?

backend headers in order to get the correct information. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --047d7b676c0692bc8d04d9db18db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 8= April 2013 15:49, John Colvin <span dir=3D"ltr">&lt;<a href=3D"mailto:john= .loughran.colvin gmail.com" target=3D"_blank">john.loughran.colvin gmail.co= m</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"im">On Mond= ay, 8 April 2013 at 00:13:29 UTC, Iain Buclaw wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex"> If only that logic held water...<br> <br> GDC actually provided the implementation of iasm to LDC. =A0Reasons why it<= br> was yanked out.<br> - one big ugly x86 special case.<br> </blockquote> <br></div> Fair enough, although I see no reason why Ds iasm shouldn&#39;t be extended= to support other architectures in the future.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex"> - depended on backend headers poisoned for use in the frontend.<br> </blockquote> <br></div> when you say poisoned, I presume you mean by the license?<div class=3D"im">= <br></div></blockquote><div><br></div><div>From system.h<br>---<br>/* Front= ends should never have to include middle-end headers.=A0 Enforce<br>=A0=A0= this by poisoning the header double-include protection defines.=A0 */<br> #ifdef IN_GCC_FRONTEND<br>#pragma GCC poison GCC_RTL_H GCC_EXCEPT_H GCC_EXP= R_H<br>#endif<br>---<br><br></div><div>The implementation of IASM required = access to rtl.h and expr.h - which is able to give you information about st= ack layout, etc.<br> </div><br><div><br>=A0</div><blockquote class=3D"gmail_quote" style=3D"marg= in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e= x"><div class=3D"im"> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex"> - frontend should not know or care about what arch it is targeting.<br> </blockquote> <br></div> what about all the other arch specific version statements? e.g. version(ARM= )<div class=3D"im"><br></div></blockquote><div><br></div><div>They are hand= led in the backend via a macro: TARGET_CPU_D_BUILTINS, TARGET_OS_D_BUILTINS= .<br> <br></div><div>If defined, these provide the frontend all version condition= s without the frontend having a large portion of code #ifdef&#39;ing all ov= er the place.<br><br><br></div><div>=A0</div><blockquote class=3D"gmail_quo= te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204= );padding-left:1ex"> <div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex"> - most iasm in druntime/phobos rely on dmd&#39;s non-standard calling conve= ntion.<br> - it has been argued in the past that gdc should not define D_InlineAsm_X86= if it does not follow dmd&#39;s ABI.<br> </blockquote> <br></div> Is it a feasible idea to automatically convert dmds inline asm to gcc&#39;s= extended inline asm?<br> <br> </blockquote></div><br></div><div class=3D"gmail_extra">This is what it did= .=A0 However as stated about it depended on poisoned backend headers in ord= er to get the correct information.<br></div><div class=3D"gmail_extra"><br = clear=3D"all"> <br><br></div><div class=3D"gmail_extra">Regards<br></div><div class=3D"gma= il_extra">-- <br>Iain Buclaw<br><br>*(p &lt; e ? p++ : p) =3D (c &amp; 0x0f= ) + &#39;0&#39;; </div></div> --047d7b676c0692bc8d04d9db18db--
Apr 08 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 8 April 2013 at 15:29:13 UTC, Iain Buclaw wrote:
 On 8 April 2013 15:49, John Colvin 
 <john.loughran.colvin gmail.com> wrote:

 On Monday, 8 April 2013 at 00:13:29 UTC, Iain Buclaw wrote:

 If only that logic held water...

 GDC actually provided the implementation of iasm to LDC.  
 Reasons why it
 was yanked out.
 - one big ugly x86 special case.

Fair enough, although I see no reason why Ds iasm shouldn't be extended to support other architectures in the future. - depended on backend headers poisoned for use in the frontend.

when you say poisoned, I presume you mean by the license? From system.h

/* Front ends should never have to include middle-end headers. Enforce this by poisoning the header double-include protection defines. */ #ifdef IN_GCC_FRONTEND #pragma GCC poison GCC_RTL_H GCC_EXCEPT_H GCC_EXPR_H #endif --- The implementation of IASM required access to rtl.h and expr.h - which is able to give you information about stack layout, etc.
  - frontend should not know or care about what arch it is 
 targeting.

what about all the other arch specific version statements? e.g. version(ARM)

TARGET_CPU_D_BUILTINS, TARGET_OS_D_BUILTINS. If defined, these provide the frontend all version conditions without the frontend having a large portion of code #ifdef'ing all over the place.
  - most iasm in druntime/phobos rely on dmd's non-standard 
 calling
 convention.
 - it has been argued in the past that gdc should not define
 D_InlineAsm_X86 if it does not follow dmd's ABI.

Is it a feasible idea to automatically convert dmds inline asm to gcc's extended inline asm?

poisoned backend headers in order to get the correct information. Regards

So, overall, it's not gonna happen unless dmd changes its implementation of inline asm?
Apr 08 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
--047d7b67880081555504d9df21a0
Content-Type: text/plain; charset=ISO-8859-1

On 8 April 2013 17:55, John Colvin <john.loughran.colvin gmail.com> wrote:

 On Monday, 8 April 2013 at 15:29:13 UTC, Iain Buclaw wrote:

 On 8 April 2013 15:49, John Colvin
<john.loughran.colvin gmail.**com<john.loughran.colvin gmail.com>>
 wrote:

  On Monday, 8 April 2013 at 00:13:29 UTC, Iain Buclaw wrote:
  If only that logic held water...
 GDC actually provided the implementation of iasm to LDC.  Reasons why it
 was yanked out.
 - one big ugly x86 special case.

to support other architectures in the future. - depended on backend headers poisoned for use in the frontend.

From system.h

/* Front ends should never have to include middle-end headers. Enforce this by poisoning the header double-include protection defines. */ #ifdef IN_GCC_FRONTEND #pragma GCC poison GCC_RTL_H GCC_EXCEPT_H GCC_EXPR_H #endif --- The implementation of IASM required access to rtl.h and expr.h - which is able to give you information about stack layout, etc.
  - frontend should not know or care about what arch it is targeting.


version(ARM) They are handled in the backend via a macro: TARGET_CPU_D_BUILTINS,

If defined, these provide the frontend all version conditions without the frontend having a large portion of code #ifdef'ing all over the place. - most iasm in druntime/phobos rely on dmd's non-standard calling
 convention.
 - it has been argued in the past that gdc should not define
 D_InlineAsm_X86 if it does not follow dmd's ABI.

extended inline asm? This is what it did. However as stated about it depended on poisoned

Regards

So, overall, it's not gonna happen unless dmd changes its implementation of inline asm?

Pretty much. Though given that what you have changed is in rt folders, I think the intent is that each compiler maintains its own, so it wouldn't be difficult just to re-implement using extended assembler. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; --047d7b67880081555504d9df21a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 8= April 2013 17:55, John Colvin <span dir=3D"ltr">&lt;<a href=3D"mailto:john= .loughran.colvin gmail.com" target=3D"_blank">john.loughran.colvin gmail.co= m</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On Monday, 8 April 2013 at= 15:29:13 UTC, Iain Buclaw wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On 8 April 2013 15:49, John Colvin &lt;<a href=3D"mailto:john.loughran.colv= in gmail.com" target=3D"_blank">john.loughran.colvin gmail.<u></u>com</a>&g= t; wrote:<br> <br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On Monday, 8 April 2013 at 00:13:29 UTC, Iain Buclaw wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> If only that logic held water...<br> <br> GDC actually provided the implementation of iasm to LDC. =A0Reasons why it<= br> was yanked out.<br> - one big ugly x86 special case.<br> <br> </blockquote> <br> Fair enough, although I see no reason why Ds iasm shouldn&#39;t be extended= to<br> support other architectures in the future.<br> <br> <br> =A0- depended on backend headers poisoned for use in the frontend.<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> </blockquote> <br> when you say poisoned, I presume you mean by the license?<br> <br> <br></div>
From system.h<br>

---<br> /* Front ends should never have to include middle-end headers. =A0Enforce<b= r> =A0 =A0this by poisoning the header double-include protection defines. =A0*= /<br> #ifdef IN_GCC_FRONTEND<br> #pragma GCC poison GCC_RTL_H GCC_EXCEPT_H GCC_EXPR_H<br> #endif<br> ---<br> <br> The implementation of IASM required access to rtl.h and expr.h - which is<b= r> able to give you information about stack layout, etc.<br> <br> <br> <br> <br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"> <br><div class=3D"im"> =A0- frontend should not know or care about what arch it is targeting.<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> </blockquote> <br> what about all the other arch specific version statements? e.g.<br> version(ARM)<br> <br> <br> </div></blockquote><div class=3D"im"> They are handled in the backend via a macro: TARGET_CPU_D_BUILTINS,<br> TARGET_OS_D_BUILTINS.<br> <br> If defined, these provide the frontend all version conditions without the<b= r> frontend having a large portion of code #ifdef&#39;ing all over the place.<= br> <br> <br> <br> <br> </div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> =A0- most iasm in druntime/phobos rely on dmd&#39;s non-standard calling<br=

x #ccc solid;padding-left:1ex"> convention.<br> - it has been argued in the past that gdc should not define<br> D_InlineAsm_X86 if it does not follow dmd&#39;s ABI.<br> <br> </blockquote> <br> Is it a feasible idea to automatically convert dmds inline asm to gcc&#39;s= <br> extended inline asm?<br> <br> <br> </blockquote></div><div class=3D"im"> This is what it did. =A0However as stated about it depended on poisoned<br> backend headers in order to get the correct information.<br> <br> <br> <br> Regards<br> </div></blockquote> <br> <br> So, overall, it&#39;s not gonna happen unless dmd changes its implementatio= n of inline asm?<br> </blockquote></div><br><br></div><div class=3D"gmail_extra">Pretty much.=A0= Though given that what you have changed is in rt folders, I think the inte= nt is that each compiler maintains its own, so it wouldn&#39;t be difficult= just to re-implement using extended assembler.<br> </div><div class=3D"gmail_extra"><br>-- <br>Iain Buclaw<br><br>*(p &lt; e ?= p++ : p) =3D (c &amp; 0x0f) + &#39;0&#39;; </div></div> --047d7b67880081555504d9df21a0--
Apr 08 2013
prev sibling parent Johannes Pfau <nospam example.com> writes:
Am Tue, 09 Apr 2013 08:14:44 +0200
schrieb Jacob Carlborg <doob me.com>:

 On 2013-04-08 22:17, Iain Buclaw wrote:
 On 8 April 2013 17:55, John Colvin <john.loughran.colvin gmail.com

     So, overall, it's not gonna happen unless dmd changes its
     implementation of inline asm?



 Pretty much.  Though given that what you have changed is in rt
 folders, I think the intent is that each compiler maintains its
 own, so it wouldn't be difficult just to re-implement using
 extended assembler.

How does GCC implement its inline assembler. What's the difference compared to how DMD implements its own?

GCC compilers always generate target-specific asm first, then the target specific assembler (as) is called to assemble that to an object file. The difference is that gcc inline asm is identical to the native assembly so it's just passed through to the assembler.
Apr 09 2013