On 8 March 2013 18:19, Artur Skawina <art.08.09@gmail.com> wrote:

> On 03/08/13 18:54, Iain Buclaw wrote:
> > Also not needed:
> > - aligned:  because D has align() for that.
>
> D's align wasn't nearly enough last time i looked. (There were changes to it since, but as I can't upgrade, haven't looked at the details)
>
> > - gnu_inline, artificial:  because D has no inline keyword, nor has need
> for one.
>
> always_inline is needed, the heuristics are not always enough. Of course it should map to just "inline".
>
>
inline and always_inline are two subtly different beasts.  But altogether I don't think either make any guarantees of an inline occuring (although always_inline is a little more relaxed about it all).

Some things are marked as always_inline anyway by gdc:  struct/class methods, lambdas and delegate literals.  Though it is probably known that this only worked within the module being compiled.  Cross-module inlining is not there yet.



>
> > - pure, const:  Although D has pure keyword that does not necessarily
> follow same as C semantics, I don't think the inclusion of these are beneficial at all.
>
> "const" may not be needed. "pure" is useful /exactly/ because of the D semantics.
>
>
Infact, strongly pure functions (where all parameters are immutable) are indeed marked as C "pure" by gdc if the functions are also nothrow. Whether this might cause some bad behaviour I'm yet to run into or find a case of...




> > - optimise, target:  I'm sure the guy who implemented these meant well,
> but I fail to see the point as to why you'd want such an attribute.
>
> They are useful. And it reminds me that last time i looked, GDC handled
> "target", "tune"
> etc wrongly:
> http://forum.dlang.org/post/mailman.1.1325716211.16222.digitalmars-d@puremagic.com
>
>
And I'd rather not want to spend time fixing it.  The code that handles these attributes are a bit bulky, and require a bit of questionable copying from the c-family frontend.


Regards
-- 
Iain Buclaw

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

On 03/08/13 19:38, Iain Buclaw wrote:
> On 8 March 2013 18:19, Artur Skawina <art.08.09@gmail.com <mailto:art.08.09@gmail.com>> wrote:
> 
>     On 03/08/13 18:54, Iain Buclaw wrote:
>     > Also not needed:
>     > - aligned:  because D has align() for that.
> 
>     D's align wasn't nearly enough last time i looked. (There were changes to
>     it since, but as I can't upgrade, haven't looked at the details)
> 
>     > - gnu_inline, artificial:  because D has no inline keyword, nor has need for one.
> 
>     always_inline is needed, the heuristics are not always enough. Of course it
>     should map to just "inline".
> 
> 
> inline and always_inline are two subtly different beasts.  But altogether I don't think either make any guarantees of an inline occuring (although always_inline is a little more relaxed about it all).
> 
> Some things are marked as always_inline anyway by gdc:  struct/class methods, lambdas and delegate literals.  Though it is probably known that this only worked within the module being compiled.  Cross-module inlining is not there yet.

Really "always_inline"? IIRC gcc throws an error if can't inline a function marked with that one - in fact that was one reason why i had to use @flatten instead of marking everything @always_inline - to avoid these errors. Things like methods should not be marked as such, as they can be huge; the inlining heuristics should be able to handle them.

>     > - pure, const:  Although D has pure keyword that does not necessarily follow same as C semantics, I don't think the inclusion of these are beneficial at all.
> 
>     "const" may not be needed. "pure" is useful /exactly/ because of the D semantics.
> 
> 
> Infact, strongly pure functions (where all parameters are immutable) are indeed marked as C "pure" by gdc if the functions are also nothrow.  Whether this might cause some bad behaviour I'm yet to run into or find a case of...

It's good to have a way to mark pure functions as such, D's pure doesn't help when the args aren't immutable, but the code is pure /logically/.


>     > - optimise, target:  I'm sure the guy who implemented these meant well, but I fail to see the point as to why you'd want such an attribute.
> 
>     They are useful. And it reminds me that last time i looked, GDC handled "target", "tune"
>     etc wrongly: http://forum.dlang.org/post/mailman.1.1325716211.16222.digitalmars-d@puremagic.com
> 
> 
> And I'd rather not want to spend time fixing it.  The code that handles these attributes are a bit bulky, and require a bit of questionable copying from the c-family frontend.

Oh, I'm just mentioning this because marking some code to be compiled for one
cpu, and having other unrelated code be mistakenly built for that cpu can result
in nasty bugs. These attributes are useful, but there are easy workarounds,
like compiling the code separately, so supporting them can indeed be very low prio.

artur

On 8 March 2013 19:00, Artur Skawina <art.08.09@gmail.com> wrote:

> On 03/08/13 19:38, Iain Buclaw wrote:
> > On 8 March 2013 18:19, Artur Skawina <art.08.09@gmail.com <mailto:
> art.08.09@gmail.com>> wrote:
> >
> >     On 03/08/13 18:54, Iain Buclaw wrote:
> >     > Also not needed:
> >     > - aligned:  because D has align() for that.
> >
> >     D's align wasn't nearly enough last time i looked. (There were
> changes to
> >     it since, but as I can't upgrade, haven't looked at the details)
> >
> >     > - gnu_inline, artificial:  because D has no inline keyword, nor
> has need for one.
> >
> >     always_inline is needed, the heuristics are not always enough. Of
> course it
> >     should map to just "inline".
> >
> >
> > inline and always_inline are two subtly different beasts.  But
> altogether I don't think either make any guarantees of an inline occuring (although always_inline is a little more relaxed about it all).
> >
> > Some things are marked as always_inline anyway by gdc:  struct/class
> methods, lambdas and delegate literals.  Though it is probably known that this only worked within the module being compiled.  Cross-module inlining is not there yet.
>
> Really "always_inline"? IIRC gcc throws an error if can't inline a
> function marked
> with that one - in fact that was one reason why i had to use @flatten
> instead of
> marking everything @always_inline - to avoid these errors. Things like
> methods
> should not be marked as such, as they can be huge; the inlining heuristics
> should
> be able to handle them.
>
> >     > - pure, const:  Although D has pure keyword that does not
> necessarily follow same as C semantics, I don't think the inclusion of these are beneficial at all.
> >
> >     "const" may not be needed. "pure" is useful /exactly/ because of the
> D semantics.
> >
> >
> > Infact, strongly pure functions (where all parameters are immutable) are
> indeed marked as C "pure" by gdc if the functions are also nothrow.
>  Whether this might cause some bad behaviour I'm yet to run into or find a
> case of...
>
> It's good to have a way to mark pure functions as such, D's pure doesn't
> help
> when the args aren't immutable, but the code is pure /logically/.
>
>
If the code is pure logically, it may be const folded away by the GCC backend given correct circumstances.  However what we don't want to happen is for it to accidentally optimise away a call that may alter an internal state that affects runtime behaviour.


Regards
-- 
Iain Buclaw

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

On Friday, 8 March 2013 at 18:16:18 UTC, Iain Buclaw wrote:

>> > > Yet not all attributes that GCC offers actually make sense to have
>> > > in D. We certainly need to have a review of each one and discuss
>> > > what is most important to have.  Also defining our own unique
>> > > attributes along the way. :o)
>> > >
I think that in pc programs there should be no need for attributes but in embedded systems they are useful.

I hope that we will get the freestanding option soon to make the code smaller and simpler.

I find need for inlining attributes in interrupts and callbacks.
For example:
Uart1_interrupt() {
  serial_int_handler(uart1);
}
Uart2_interrupt() {
  serial_int_handler(uart2);
}
...
Here I need to control whether I want to duplicate the handler code because of speed or do I want to save memory by not inlining.


Target options are useful when the same program is used in different processor families. The general code should be targeted to run in all versions of hardware and product specific code may be targeted to the actual processor used.
For example: in the products I make, the battery powered versions use Cortex-m3 and mains powered versions use Cortex-m4

I have also found an use for optimize: a while ago I pointed out that global variables are optimized out in loops. Now I have to compile separately those files that access volatile registers, with no optimization. The other files I compile with optimizations.