On Sunday, 26 April 2015 at 00:52:56 UTC, Mike wrote:
> On Saturday, 25 April 2015 at 16:32:50 UTC, Timo Sintonen wrote:

> I think there's a few gems that can be cherry-picked out of Phobos, especially for metaprogramming:
>
> std.traits
> std.typecons
> std.typetuple
>
> There are also a couple things in these libraries that might be useful for programming in general:
>
> std.conv
> std.string
> std.array
>
> Mike

Yes. This has been in my plans but I have not hurried because:

-Import mess. Phobos files import several other files. Some of them cannot be used. Work is going on to remove unnecessary imports and use scoped imports. It is important that imports for unittests are only in unittest blocks.

-All functions have to be nogc. Active work is going on also in this area.

The files should just be tried one by one to see if they can be compiled.

On 4/25/2015 10:02 PM, Timo Sintonen via Digitalmars-d-learn wrote:
> -Import mess. Phobos files import several other files. Some of them
> cannot be used. Work is going on to remove unnecessary imports and use
> scoped imports. It is important that imports for unittests are only in
> unittest blocks.
>
> -All functions have to be nogc. Active work is going on also in this area.
>
> The files should just be tried one by one to see if they can be compiled.

It's important to note that most of the work occurring on these fronts is use-case driven.  Not much is happening for the sake of completeness (except to some degree by Walter).  So, your needs where they don't overlap with someone else's needs, might well take a long time to get done unless you do some of the driving.

Even tackling the improvement of one or two api's helps drive towards completion.

Am Sun, 26 Apr 2015 00:14:42 +0000
schrieb "Mike" <none@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

On Friday, 24 April 2015 at 22:18:22 UTC, tom wrote:
> On Friday, 24 April 2015 at 13:12:56 UTC, Jens Bauer wrote:
>> On Friday, 24 April 2015 at 07:34:55 UTC, tom wrote:
>>> would something like a STM32 NUCLEO-F401RE work?
>>
>> I forgot to give you a proper answer on this one: I think it should work, as it's a STM32F401 microcontroller.
>
> ill order a discover, i have to try this out.
> http://www.digikey.com/product-detail/en/STM32F4DISCOVERY/497-11455-ND/2711743
> this one right?

Tom, I'm curious - did you get a board ? :)