version statement problem in gdc
John Colvin
john.loughran.colvin at gmail.com
Mon Apr 8 09:55:12 PDT 2013
On Monday, 8 April 2013 at 15:29:13 UTC, Iain Buclaw wrote:
> On 8 April 2013 15:49, John Colvin
> <john.loughran.colvin at 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?
More information about the D.gnu
mailing list