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