Am Sun, 26 Apr 2015 00:14:42 +0000
schrieb "Mike" <n...@none.com>:

> >
> > Usage:
> >     auto b = PORTB.load();
> >     PORTB.toggle!"PIN0";
> >     PORTB.PIN0 = Level.low;
> >     writeln(PORTB.PIN0);
> >     PORTB.TEST = 0b000;
> >
> 
> That's some nice code! and really leveraging D to great effect.  
> I know that Volatile!(T) took some engineering to get right, so 
> it would be nice to have that as an "official" type IMO.
> 

It should certainly be in druntime in the long term. But first it needs
quite some testing. Maybe I'll propose it for std.experimental or I'll
create a dub-package first.

> >
> > The remaining problem is performance. (With optimization the 
> > generated
> > code is as good as equivalent C code. However, we need to avoid 
> > size
> > overhead: e.g. struct initializers and the opX functions 
> > shouldn't
> > generate functions in the executable, though tha can be fixed 
> > with the
> > linker)
> 
> I'm not sure I follow how the linker can solve this.  Could you 
> elaborate?

That was a sloppily written statement, sorry. Performance as in speed /
number of instructions / cycles is not an issue with optimization.

Default initialization is a problem as even all-zero initializers go
into bss right now. So we need n bytes per struct type in the bss
section. (For the register wrapper every register is a type). If they
went into rodata instead and if the linker merges all-zero symbols then
the overhead is limited to the biggest used struct size. I'm not sure if
linkers do this optimization.

For small functions (the generated properties, operator overloads) the
problem is that these are always force-inlined for performance but we
still output a complete function (in order to give the function a valid
address and similar things). The linker can remove these with
-ffunction-sections and --gc-sections. It might still be nice to have
'static (force)inline' / 'extern (force)inline' semantics[1][2][3].

[1] http://stackoverflow.com/a/216546/471401
[2] http://www.greenend.org.uk/rjk/tech/inline.html
[3] https://gcc.gnu.org/onlinedocs/gcc/Inline.html

Reply via email to