GDC review process.

[Iain Buclaw]

On 20 June 2012 17:44, deadalnix <deadalnix at gmail.com> wrote:
> 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
> ?

Make an unaccurate guess of where a variable is located in relation to
the stack frame. :-)

Most actions are reasonably simple to deduce and convert. There are
lots of notable exceptions though:

ptr[1] = &foo;
asm
{
        jmp ptr[1*4];
}

May produce a number of variants depending on whether ptr is a local,
parameter, static, shared, thread local, or whether you are running
Linux or Windows  :-)


But it's code like this that is the worst reason for removal:

int zz( int p1 )
{
    asm
    {
        naked;
        mov EAX, p1[EBP];
    }
}

Here, depending on what optimisation you have turned on, p1 could be
passed on the stack, or in a register.  So how do you plan to work out
what value you are mov'ing to EAX without knowledge of the function
frame that the GCC backend sets up in RTL.  Information that the
frontend should never have access to (and is #poison'd to enforce
this) ?


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';