GDC review process.

[deadalnix]

Le 20/06/2012 18:40, Iain Buclaw a écrit :
> On 20 June 2012 17:23, deadalnix<deadalnix at gmail.com>  wrote:
>> Le 20/06/2012 18:18, Iain Buclaw a écrit :
>>>
>>> On 20 June 2012 17:00, Brad Anderson<eco at gnuk.net>    wrote:
>>>>
>>>> On Tue, Jun 19, 2012 at 12:19 PM, Iain Buclaw<ibuclaw at ubuntu.com>    wrote:
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Had round one of the code review process, so I'm going to post the main
>>>>> issues here that most affect D users / the platforms they want to run on
>>>>> /
>>>>> the compiler version they want to use.
>>>>>
>>>>>
>>>>>
>>>>> 1) D Inline Asm and naked function support is raising far too many alarm
>>>>> bells. So would just be easier to remove it and avoid all the other
>>>>> comments
>>>>> on why we need middle-end and backend headers in gdc.
>>>>>
>>>>>
>>>>> 2) Code with #if V1 and V2 raised another bell with the request to
>>>>> remove
>>>>> all code that relies on internal macros with proper if() conditions. If
>>>>> something is always going to be turned off, remove it.
>>>>>
>>>>> So, we shall also be saying bye bye D1 in GDC.  We'll miss you!
>>>>>
>>>>>
>>>>> 3) For anyone who has submitted patches for Mingw and Apple - sorry, but
>>>>> I'm going to have to yank out or alter certain bits.  Apple GCC is
>>>>> irrelevant now, and some Mingw checks look for if(target) when it should
>>>>> really be checking if(host) and vice versa!
>>>>>
>>>>>
>>>>> Most discussion I would imagine be on the decision to remove D inline
>>>>> assembler support from gdc.  So, nay sayers, do your worst, but
>>>>> unfortunately there is a +1 here for removal.
>>>>>
>>>>>
>>>>> Regards
>>>>> Iain
>>>>
>>>>
>>>>
>>>> I'm very much outside of my area of understanding but would it be
>>>> possible
>>>> to use CTFE+mixin to generate GCC asm from DMD style asm allowing people
>>>> to
>>>> still use a single version of the asm for both DMD and GDC?
>>>>
>>>> Regards,
>>>> Brad Anderson
>>>
>>>
>>> Hmm... doable, yes, but it would require a similarly complex construct
>>> as the implementation in the compiler.  GCC Assembler is much more
>>> expressive than D Inline Assembler, and requires for you to describe
>>> everything a given asm command is doing, inputs, outputs, clobbers,
>>> and labels that we may jump to (if any).   The only thing I worry is
>>> that CTFE is not powerful enough process a long set of instructions at
>>> a fast enough rate to make it benefitial.
>>>
>>
>> Can't gdc frontend process asm to gcc's asm and go from that ?
>
> It's what we did, but there's a lot of information that we require
> about, eg: the function frame pointer, that is not available to the
> frontend when trying to re-create just exactly what the assembly code
> is requiring us to do.
>

So, how does the programer is supposed to handle that when writing gcc's 
asm ?