View mode: basic / threaded / horizontal-split · Log in · Help
June 20, 2012
Re: GDC review process.
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 ?
June 20, 2012
Re: GDC review process.
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';
June 20, 2012
Re: GDC review process.
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
June 20, 2012
Re: GDC review process.
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.
June 20, 2012
Re: GDC review process.
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
June 20, 2012
Re: GDC review process.
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.
June 20, 2012
Re: GDC review process.
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
June 20, 2012
Re: GDC review process.
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
June 21, 2012
Re: GDC review process.
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.
June 21, 2012
Re: GDC review process.
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.
6 7 8 9 10 11
Top | Discussion index | About this forum | D home