version statement problem in gdc

[Iain Buclaw]

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
-- 
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/1ddd919b/attachment.html>