On 1/5/2012 1:22 PM, Manu wrote:
> Love to. I'll give it some thorough thought. There's more details than I think
> most would expect...

I know the devil is in the details :-)

Anyhow, please start a new topic for that one. This thread is getting too large.

On 5 January 2012 23:03, Sean Kelly <sean@invisibleduck.org> wrote:

> > I think they are all language requests. They could be implemented by 3rd
> party compilers, but these things are certainly nice to standardise in the language, or you end up with C, which is a mess I'm trying to escape.
>
> It's a grey area I suppose.  Half of the features you list don't change the language, they simply allow the compiler to make optimizations it otherwise couldn't.  I suppose the D way would be to make them '@' prefixed and provide some means for having the compiler ignore them if it didn't recognize them.  This wouldn't fragment the language so much as make generated code more efficient on supporting platforms.
>

Precisely. That's all I want :) .. formal definition of these concepts, allowing GDC and co to feed that information through to the backend which already supports these concepts :)


> Could a vector type be defined in the library?  Aside from alignment, there doesn't seem to be anything that requires compiler support.  Or am I missing something?
>

I think there's a lot you're missing. Load/store patterns, register allocation, parameter argument convention (ABI details), literals and assignment, exception handling/error conditions, and alignment... The actual working functional stuff could/would be done in a library, but even then, if the opcode intrinsic names weren't standardised, it'd be an awful mess behind the scenes aggregating all the different names/terminology from each compiler implementation.

>   * inline asm supporting pseudo regs - As an extension of using the
> vector hardware, I'll need inline asm, and inline assembly without pseudo
> regs is pretty useless... it's mandatory that the compiler shedule the
> register allocation otherwise inline asm will most likely be an
> un-optimisation. If D had pseudo regs in its inline assembler, it would
> make it REALLY attractive for embedded systems programmers.
>
> This would certainly be nice.  When I drop into ASM I generally could care less about which actual register I use.  I just want to call something specific.
>

It's usually actually disruptive to the program around the inline asm block
if you are naming registers explicitly.. better to let the compiler assign
them, and intelligently flush values to the stack if it runs out of
registers.
AT&T asm syntax allows this, you define 'parameter' types using some silly
string, and then refer to %1, %2, %3 in place of registers in your asm
code, and it will perform the register assignment.
Most C compilers also don't allow program optimisation/rescheduling around
inline asm blocks, this makes them useless, and I'll bet GDC suffers the
same problem right now(...?)

>   * __restrict - Not a deal breaker, but console game dev industry uses
> this all the time. There are countless articles on the topic (many are
> private or on console vendor forums). If this is not standardised in the
> language, GDC will still expose it I'm sure, fragmenting the language.
> >
> >   * __forceinline - I'd rather have a proper keyword than using tricks
> like mixins and stuff as have been discussed. The reason for this is debugging. Code is not-inlined in debug builds, looks&feels like normal code, can still evaluate, and step like regular code... and guarantee that it inlines properly when optimised. This just saves time; no frills debugging.
>
> I'd say these are QOI issues, as above.
>

Yup, so just standardise the names for these attributes and pass the info through to GCC's back end... done :) ... Although I'm sure __forceinline isn't so simple.


> >   * multiple return values - This is a purely idealistic feature
> request, but would lead to some really nice optimisations while retaining very tidy code if implemented properly. Other languages support this, it's a nice modern feature... why not have it in D?
>
> I can see the ABI rules for this getting really complicated, much like how parameter passing rules on x64 are insanely complex compared to x32.  But I agree that it would be a nice feature to have.
>

How so? Parameters are passed in a sequence of regs of the appropriate
type, to a point, at which stage they get put on the stack... is x64
somehow more complicated than that?
Multiple return values would use the exact same regs in reverse. There
should be no side effects, the calling function has already (or has the
caoability to) stored off any save regs in order to pass args in the first
place.

> I couldn't release the games I do without efficient use of vector
> hardware and __restrict used in appropriate places. I use them every day,
> and I wouldn't begin a project in D without knowing that these features are
> supported, or are definitely coming to the language.
>
> I know it's a major time commitment, but the best way to realize any new feature quickly is to create a pull request.  Feature proposals have a way of being lost if they never extend beyond this newsgroup.


Fair call, but I don't have time to get involved in that level right now,
not by a long shot.
I'm just a potential customer trying to give it a fair go at this point...
;)

On 5 January 2012 23:30, Walter Bright <newshound2@digitalmars.com> wrote:

> On 1/5/2012 8:49 AM, Manu wrote:
>
>> I also wonder if the D language provides some opportunities for
>> optimisation
>> that aren't expressible in other languages,
>>
>
> There are some. One that is currently being exploited by the optimizer and back end is the existence of pure functions.


Does GDC currently support these same optimisations, or is this a DMD special power?

On 5 January 2012 20:36, Manu <turkeyman@gmail.com> wrote:
> On 5 January 2012 21:41, Sean Kelly <sean@invisibleduck.org> wrote:
>>
>> On Jan 5, 2012, at 10:02 AM, Manu wrote:
>> >
>> > That said, this is just one of numerous issues myself and the OP raised.
>> > I don't know why this one became the most popular for discussion... my
>> > suspicion is that is because this is the easiest of my complaints to dismiss
>> > and shut down ;)
>>
>> It's also about the only language change among the issues you mentioned.  Most of the others are QOI issues for compiler vendors.  What I've been curious about is if you really have a need for the performance that would be granted by these features, or if this is more of an idealistic issue.
>
>
> I think they are all language requests. They could be implemented by 3rd party compilers, but these things are certainly nice to standardise in the language, or you end up with C, which is a mess I'm trying to escape.
>
> Of the topics been discussed:
>   * vector type - I can't be expected to write a game without using the
> vector hardware... I'd rather use a portable standardised type than a GDC
> extension. Why the resistance? I haven't heard any good arguments against,
> other than some murmurings about float[4] as the official syntax, which I
> gave detailed arguments against.
>

I dabbled with vector types, none of the vector builtins are hashed out to GDC because it really does require that vector be a unique type from a normal array.

>   * inline asm supporting pseudo regs - As an extension of using the vector
> hardware, I'll need inline asm, and inline assembly without pseudo regs is
> pretty useless... it's mandatory that the compiler shedule the register
> allocation otherwise inline asm will most likely be an un-optimisation. If D
> had pseudo regs in its inline assembler, it would make it REALLY attractive
> for embedded systems programmers.
>     In lieu of that, I need to use opcode intrinsics instead, which I
> believe GDC exposes, but again, I'm done with C and versioning (#ifdef-ing)
> every compiler I intend to use. Why not standardise these things? At least
> put the intrinsics in the standard lib...
>

This is only possible using GDC extended asm - which is really GCC asm but encapsulated in {} instead of ();

>   * __restrict - Not a deal breaker, but console game dev industry uses this all the time. There are countless articles on the topic (many are private or on console vendor forums). If this is not standardised in the language, GDC will still expose it I'm sure, fragmenting the language.
>

I don't think D enforces any sort of aliasing rules, but it would be nice to turn on strict aliasing though...

>   * __forceinline - I'd rather have a proper keyword than using tricks like mixins and stuff as have been discussed. The reason for this is debugging. Code is not-inlined in debug builds, looks&feels like normal code, can still evaluate, and step like regular code... and guarantee that it inlines properly when optimised. This just saves time; no frills debugging.
>

__forceinline still won't be a guarantee though.


-- 
Iain Buclaw

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

On Jan 5, 2012, at 1:42 PM, Manu wrote:

> Most C compilers also don't allow program optimisation/rescheduling around inline asm blocks, this makes them useless, and I'll bet GDC suffers the same problem right now(…?)

Not sure about GDC.  At one time, I pushed for keeping "volatile" alive so asm blocks could be labeled to tell the compiler not to optimize across them.  I recall Walter rejecting the idea because compilers shouldn't optimize across asm blocks.  This should probably be revisited at some point.


> >   * __restrict - Not a deal breaker, but console game dev industry uses this all the time. There are countless articles on the topic (many are private or on console vendor forums). If this is not standardised in the language, GDC will still expose it I'm sure, fragmenting the language.
> >
> >   * __forceinline - I'd rather have a proper keyword than using tricks like mixins and stuff as have been discussed. The reason for this is debugging. Code is not-inlined in debug builds, looks&feels like normal code, can still evaluate, and step like regular code... and guarantee that it inlines properly when optimised. This just saves time; no frills debugging.
> 
> I'd say these are QOI issues, as above.
> 
> Yup, so just standardise the names for these attributes and pass the info through to GCC's back end... done :) ... Although I'm sure __forceinline isn't so simple.

I'm sure it isn't.  Though as long as compilers aren't required to support it, it's just a matter of making it work, right: ;-)


> >   * multiple return values - This is a purely idealistic feature request, but would lead to some really nice optimisations while retaining very tidy code if implemented properly. Other languages support this, it's a nice modern feature... why not have it in D?
> 
> I can see the ABI rules for this getting really complicated, much like how parameter passing rules on x64 are insanely complex compared to x32.  But I agree that it would be a nice feature to have.
> 
> How so? Parameters are passed in a sequence of regs of the appropriate type, to a point, at which stage they get put on the stack... is x64 somehow more complicated than that?
> Multiple return values would use the exact same regs in reverse. There should be no side effects, the calling function has already (or has the caoability to) stored off any save regs in order to pass args in the first place.

No, that's exactly how x64 works.  But compared to x32 where everything is simply pushed onto the stack…  That's all I was saying.


> Fair call, but I don't have time to get involved in that level right now, not by a long shot. I'm just a potential customer trying to give it a fair go at this point... ;)

Then please be as specific as you can :-)  Don might have some experience in this area, but I suspect Walter does not.

On 5 January 2012 23:34, Walter Bright <newshound2@digitalmars.com> wrote:

> On 1/5/2012 3:58 AM, Manu wrote:
>
>> How is this possible, when all functions are virtual, without whole
>> program
>> optimisation?
>>
>
> Only public non-final class member functions are virtual. Furthermore, as in C++, the compiler can sometimes determine that a virtual function is being called directly, and will do so (or inline it).
>

Can you define 'sometimes'? I have trouble believing that this will occur very often. The stars aligning to that level of precision seems totally unreliable.

Consider the UI code snippet I posted earlier (I've lost the link), most
functions are public and not virtual (mostly accessors, or fairly simple
mutators), and they could only be identified to be not-overridden with
whole program optimisation...
The fact you mention potential for inline-ing actually heightens my
criticism with another detail I hadn't considered ;) ... Now all my trivial
methods won't only be virtual-called, they won't be inlined either!

I'm genuinely scared of people forgetting to type final (including myself)... And it's hard as an external coder to go and clean up too. Adding final blocks to someone elses existing code, you don't necessarily know what is truly virtual or not... *mumble mumble*

On 5 January 2012 23:50, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> >   * inline asm supporting pseudo regs - As an extension of using the
> vector
> > hardware, I'll need inline asm, and inline assembly without pseudo regs
> is
> > pretty useless... it's mandatory that the compiler shedule the register allocation otherwise inline asm will most likely be an un-optimisation.
> If D
> > had pseudo regs in its inline assembler, it would make it REALLY
> attractive
> > for embedded systems programmers.
> >     In lieu of that, I need to use opcode intrinsics instead, which I
> > believe GDC exposes, but again, I'm done with C and versioning
> (#ifdef-ing)
> > every compiler I intend to use. Why not standardise these things? At
> least
> > put the intrinsics in the standard lib...
> >
>
> This is only possible using GDC extended asm - which is really GCC asm but encapsulated in {} instead of ();
>

... shit.
I fear this is a VERY serious problem that needs discussion and resolution.
Now we have 2 competing standards of asm syntax in D...
We're exactly in the same place as VisualC and GCC now. Epic fail.

On 5 January 2012 16:49, Manu <turkeyman@gmail.com> wrote:
>> D is not a compiler, it is a language. Furthermore it is not true that DMDs backend is rubbish and there are already more backends than just the DMC backend.
>
>
> Sorry, I was generalising a little general in that claim. And where I say
> 'rubbish', I was drawing comparison to the maturity of C compilers for x86,
> which STILL have trouble and make lots of mistakes with centuries of man
> hours of work.
> DMD has inferior code gen (there was a post last night comparing some
> disassemblies of trivial programs with GDC), will probably never rival GCC,
> that's fine, it's a reference, I get that.
> But to say that using GDC will magically fix code gen is also false. I'm not
> familiar with the GCC code, so I may be wrong, but my understanding is that
> there is frontend work, and frontend-GCC glue work that will allow for back
> end optimisation (which GCC can do quite well) to work properly. This is
> still a lot of work for a small OSS team.
> I also wonder if the D language provides some opportunities for optimisation
> that aren't expressible in other languages, and therefore may not already
> have an expression in the GCC back end... so I can imagine some of future
> optimisations frequently discussed in this forum won't just magically appear
> with GCC/LLVM maturity. I can't imagine Iain and co extending the GCC back
> end to support some obscure D optimisations happening any time soon.
>

Actually, it's just me. ;)

So far I have come across no D optimisations that aren't supported in GCC.  Infact, most of the time I find myself thinking of how I can use obscure GCC optimisation X to improve D.    One example is an interesting feature of Fortran, though written with C++ in mind. Seems like something that could be right up D's street.

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=147822

-- 
Iain Buclaw

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

On 5 January 2012 23:53, Sean Kelly <sean@invisibleduck.org> wrote:

> I recall Walter rejecting the idea because compilers shouldn't optimize across asm blocks.  This should probably be revisited at some point.
>

It's proven then, inline asm blocks break the optimiser... they are officially useless. This is why all C coders use intrinsics these days, and D should too.


> > How so? Parameters are passed in a sequence of regs of the appropriate
> type, to a point, at which stage they get put on the stack... is x64 somehow more complicated than that?
> > Multiple return values would use the exact same regs in reverse. There
> should be no side effects, the calling function has already (or has the caoability to) stored off any save regs in order to pass args in the first place.
>
> No, that's exactly how x64 works.  But compared to x32 where everything is simply pushed onto the stack…  That's all I was saying.
>

Ah yes, I forgot... x86 is such a shit architecture! ;) .. I rarely write
x86 code, it's fairly pointless usually. Chips don't execute the opcodes
you write anyway, they reinterpret and microcode them.. you can never know
what's best, and it's different for every x86 processor/vendor :P
Despite the assembly you read, x86 doesn't REALLY push all those args to
the stack, they have much larger register banks internally, and use them...
finally, x64 put an end to the nostalgic x86 nonsense :)

On 5 January 2012 22:01, Manu <turkeyman@gmail.com> wrote:
> On 5 January 2012 23:50, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>>
>> >   * inline asm supporting pseudo regs - As an extension of using the
>> > vector
>> > hardware, I'll need inline asm, and inline assembly without pseudo regs
>> > is
>> > pretty useless... it's mandatory that the compiler shedule the register
>> > allocation otherwise inline asm will most likely be an un-optimisation.
>> > If D
>> > had pseudo regs in its inline assembler, it would make it REALLY
>> > attractive
>> > for embedded systems programmers.
>> >     In lieu of that, I need to use opcode intrinsics instead, which I
>> > believe GDC exposes, but again, I'm done with C and versioning
>> > (#ifdef-ing)
>> > every compiler I intend to use. Why not standardise these things? At
>> > least
>> > put the intrinsics in the standard lib...
>> >
>>
>> This is only possible using GDC extended asm - which is really GCC asm but encapsulated in {} instead of ();
>
>
> ... shit.
> I fear this is a VERY serious problem that needs discussion and resolution.
> Now we have 2 competing standards of asm syntax in D...
> We're exactly in the same place as VisualC and GCC now. Epic fail.

Why?

The reasoning behind is more so that you can write asm statements on all architectures, not just x86. And with GDC being a frontend of GCC, seems a natural thing to support (this has actually been in GDC since 2004, so I'm not sure why you should through all arms up about it now).


-- 
Iain Buclaw

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