Thread overview | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
April 07, 2013 version statement problem in gdc | ||||
---|---|---|---|---|
| ||||
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 |
April 07, 2013 Re: version statement problem in gdc | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin | 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.
|
April 08, 2013 Re: version statement problem in gdc | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin Attachments:
| 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'; |
April 08, 2013 Re: version statement problem in gdc | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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 |
April 08, 2013 Re: version statement problem in gdc | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin Attachments:
| 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'; |
April 08, 2013 Re: version statement problem in gdc | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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?
|
April 08, 2013 Re: version statement problem in gdc | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin Attachments:
| 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'; |
April 09, 2013 Re: version statement problem in gdc | ||||
---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | 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 |
April 09, 2013 Re: version statement problem in gdc | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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.
|
April 09, 2013 Re: version statement problem in gdc | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | 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 |
Copyright © 1999-2021 by the D Language Foundation