version statement problem in gdc

[Iain Buclaw]

On 8 April 2013 17:55, John Colvin <john.loughran.colvin at 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 at gmail.**com<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?
>


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';
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20130408/670db7d3/attachment.html>