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
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 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
parent reply "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
parent reply 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
parent reply "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
parent reply 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
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 reply 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
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