Le 20/06/2012 18:40, Iain Buclaw a écrit :
> On 20 June 2012 17:23, deadalnix<deadalnix@gmail.com>  wrote:
>> Le 20/06/2012 18:18, Iain Buclaw a écrit :
>>>
>>> On 20 June 2012 17:00, Brad Anderson<eco@gnuk.net>    wrote:
>>>>
>>>> On Tue, Jun 19, 2012 at 12:19 PM, Iain Buclaw<ibuclaw@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 ?

On 20 June 2012 17:44, deadalnix <deadalnix@gmail.com> wrote:
> Le 20/06/2012 18:40, Iain Buclaw a écrit :
>>
>> On 20 June 2012 17:23, deadalnix<deadalnix@gmail.com>  wrote:
>>
>>> Le 20/06/2012 18:18, Iain Buclaw a écrit :
>>>>
>>>>
>>>> On 20 June 2012 17:00, Brad Anderson<eco@gnuk.net>    wrote:
>>>>>
>>>>>
>>>>> On Tue, Jun 19, 2012 at 12:19 PM, Iain Buclaw<ibuclaw@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';

On Wednesday, 20 June 2012 at 16:09:14 UTC, Jonathan M Davis wrote:
> But inline assembler with the syntax that dmd uses is supposed to be part of
> the language. So, if gdc doesn't support it, it's not a fully compliant D
> compiler.

I am not too sure about that: In my opinion, your description of the problem would be accurate if some compiler implemented asm {}, but with a different syntax or different semantics. But GDC simply does not (resp. will not) implement D-style inline assembly at all. From my point of view, this is not necessarily a problem spec-wise, as it is not guaranteed to be available – if it was, there would be no reason to have D_InlineAsm_X86 at all.

Needless to say, inline assembly is sometimes a very convenient feature to have, but if it is the only issue stopping GDC from being merged to mainline GCC, I'd say the only sensible choice is to yank it, at least it for the time being. If, at a later point, somebody comes up with a clever way to implement it given the constraints imposed by the GCC infrastructure, or manages to convince the GCC maintainers to accept the »dirty« solution, it could still be added in again.

David

On 20/06/12 18:10, David Nadlinger wrote:
> I am not too sure about that: In my opinion, your description of the problem
> would be accurate if some compiler implemented asm {}, but with a different
> syntax or different semantics. But GDC simply does not (resp. will not)
> implement D-style inline assembly at all. From my point of view, this is not
> necessarily a problem spec-wise, as it is not guaranteed to be available – if it
> was, there would be no reason to have D_InlineAsm_X86 at all.

Reading http://dlang.org/iasm.html I don't have the impression that the inline assembler is an optional part of the D spec or not guaranteed to be available -- it's very deliberately intended to be there.

> Needless to say, inline assembly is sometimes a very convenient feature to have,
> but if it is the only issue stopping GDC from being merged to mainline GCC, I'd
> say the only sensible choice is to yank it, at least it for the time being. If,
> at a later point, somebody comes up with a clever way to implement it given the
> constraints imposed by the GCC infrastructure, or manages to convince the GCC
> maintainers to accept the »dirty« solution, it could still be added in again.

For sure it make sense as a short-term compromise, but I don't see how GDC can meet the D specifications without implementing the inline assembler at some point in the (hopefully near) future.  When you consider that GDC is the best bet for being able to compile D on ARM processors, and a major application here is embedded systems, it really seems necessary to plan to have this functionality in there.

On 20-06-2012 21:08, Joseph Rushton Wakeling wrote:
> On 20/06/12 18:10, David Nadlinger wrote:
>> I am not too sure about that: In my opinion, your description of the
>> problem
>> would be accurate if some compiler implemented asm {}, but with a
>> different
>> syntax or different semantics. But GDC simply does not (resp. will not)
>> implement D-style inline assembly at all. From my point of view, this
>> is not
>> necessarily a problem spec-wise, as it is not guaranteed to be
>> available – if it
>> was, there would be no reason to have D_InlineAsm_X86 at all.
>
> Reading http://dlang.org/iasm.html I don't have the impression that the
> inline assembler is an optional part of the D spec or not guaranteed to
> be available -- it's very deliberately intended to be there.
>
>> Needless to say, inline assembly is sometimes a very convenient
>> feature to have,
>> but if it is the only issue stopping GDC from being merged to mainline
>> GCC, I'd
>> say the only sensible choice is to yank it, at least it for the time
>> being. If,
>> at a later point, somebody comes up with a clever way to implement it
>> given the
>> constraints imposed by the GCC infrastructure, or manages to convince
>> the GCC
>> maintainers to accept the »dirty« solution, it could still be added in
>> again.
>
> For sure it make sense as a short-term compromise, but I don't see how
> GDC can meet the D specifications without implementing the inline
> assembler at some point in the (hopefully near) future. When you
> consider that GDC is the best bet for being able to compile D on ARM
> processors, and a major application here is embedded systems, it really
> seems necessary to plan to have this functionality in there.

And x86 inline assembler... on ARM? I don't think I follow.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On 20/06/12 20:35, Alex Rønne Petersen wrote:
> And x86 inline assembler... on ARM? I don't think I follow.

If I understand http://dlang.org/iasm.html correctly, the idea is that D should have an inline assembler for each target architecture.

AFAICS what's desired is that you should be able to insert

	asm
	{
		// target-specific assembly goes here
	}

... and have it accepted by _any_ D compiler.  That seems to me to be an important part of the language in general and even more so on architectures that are suited to embedded systems.  So while it may make sense to cut the inline assembly in the short term for GDC, it doesn't make sense to me for it to be a change that lasts.

On Wednesday, 20 June 2012 at 19:08:43 UTC, Joseph Rushton Wakeling wrote:
> Reading http://dlang.org/iasm.html I don't have the impression that the inline assembler is an optional part of the D spec or not guaranteed to be available -- it's very deliberately intended to be there.

… yet code is only to assume it is actually available if D_InlineAsm_x86 is defined?

I don't want to argue about the fact that there is certainly code out there which assumes inline x86 assembly to be available. My point was that this is _not_ like Jonathan's »auto a = expression« vs. »expression = a auto« example, because the language contains specific provisions for inline assembly not being available by having a standardized D_InlineAsm_x86 version identifier.

David

On 20-06-2012 21:48, Joseph Rushton Wakeling wrote:
> On 20/06/12 20:35, Alex Rønne Petersen wrote:
>> And x86 inline assembler... on ARM? I don't think I follow.
>
> If I understand http://dlang.org/iasm.html correctly, the idea is that D
> should have an inline assembler for each target architecture.
>
> AFAICS what's desired is that you should be able to insert
>
> asm
> {
> // target-specific assembly goes here
> }
>
> .... and have it accepted by _any_ D compiler. That seems to me to be an
> important part of the language in general and even more so on
> architectures that are suited to embedded systems. So while it may make
> sense to cut the inline assembly in the short term for GDC, it doesn't
> make sense to me for it to be a change that lasts.

GDC currently supports x86, ARM, PowerPC, MIPS, SPARC, and possibly others. The language reference lists assembly syntax for x86. I understand that in an ideal world, we'd have standardized assembly syntaxes for all of these architectures, but somebody has to actually spec and implement them.

Besides, Iain has already pointed out that the x86 syntax in the spec doesn't integrate with GCC's inline assembly support at all (which is why GDC had the glue code for it). It took around 2000 lines (if memory serves) to translate the D inline assembly to GCC inline assembly. Now imagine having to do this for every architecture ever supported.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On 6/20/2012 4:26 AM, Bernard Helyer wrote:
> I was sputtering with rage. Sputtering!

Look Dave, I can see you're really upset about this. I honestly think you ought to sit down calmly, take a stress pill, and think things over. I know I've made some very poor decisions recently, but I can give you my complete assurance that my work will be back to normal.

On Tuesday, 19 June 2012 at 18:19:01 UTC, Iain Buclaw wrote:

> 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.

I'll give my opinion. I have yet to write some x86 assembly and only have anticipations of playing around in it, so take this with as much force as you desire.

D specifies inline ASM, I don't see this GCC submission dictating its removal. So I think it would be best to actually support D.

Now, the way you phrase this statement it sounds like it will be harder to get through the review and as there might be many changes to get the ASM support through. In which case I think postponing inline ASM support to get through an initial review and approval is fine. But it should be considered only temporary and should get approval based on the knowledge inline ASM will be coming.

The other items do not appear relevant to supporting the D specification, and we are halfway to DigitalMars not supporting a D1 compiler.