D.gnu - version statement problem in gdc

John Colvin (13/13) Apr 07 2013 void main() {

John Colvin (5/18) Apr 07 2013 Ah, I see D inline asm isn't supported in gdc. When I removed the

Iain Buclaw (20/38) Apr 07 2013 check from my code I got a massive slew of errors telling me so (one for

John Colvin (20/32) Apr 08 2013 Fair enough, although I see no reason why Ds iasm shouldn't be

Iain Buclaw (20/44) Apr 08 2013 ---

John Colvin (3/72) Apr 08 2013 So, overall, it's not gonna happen unless dmd changes its

Iain Buclaw (7/86) Apr 08 2013 Pretty much. Though given that what you have changed is in rt folders, ...

Jacob Carlborg (5/11) Apr 08 2013 How does GCC implement its inline assembler. What's the difference

Johannes Pfau (6/22) Apr 09 2013 GCC compilers always generate target-specific asm first, then the

Jacob Carlborg (4/8) Apr 09 2013 Aha, I see.

"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

"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

Iain Buclaw <ibuclaw ubuntu.com> writes:

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

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.

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';

Apr 07 2013

"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

Iain Buclaw <ibuclaw ubuntu.com> writes:

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)

They are handled in the backend via a macro: 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?

This is what it did.  However as stated about it depended on poisoned
backend headers in order to get the correct information.



Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Apr 08 2013

"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)

 They are handled in the backend via a macro: 
 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?

 This is what it did.  However as stated about it depended on 
 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

Iain Buclaw <ibuclaw ubuntu.com> writes:

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.

 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)


  They are handled in the backend via a macro: 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?


  This is what it did.  However as stated about it depended on 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?


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';

Apr 08 2013

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

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

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

D Programming

C/C++ Programming

Other

D.gnu - version statement problem in gdc