http://www.reddit.com/r/programming/comments/2aoqov/dconf_2014_day_2_talk_7_tiny_ubiquitous_machines/

https://www.facebook.com/dlang.org/posts/884725944874421

https://twitter.com/D_Programming/status/488748669869780992


Andrei

On Monday, 14 July 2014 at 18:17:25 UTC, Andrei Alexandrescu wrote:
> http://www.reddit.com/r/programming/comments/2aoqov/dconf_2014_day_2_talk_7_tiny_ubiquitous_machines/
>
> https://www.facebook.com/dlang.org/posts/884725944874421
>
> https://twitter.com/D_Programming/status/488748669869780992
>
>
> Andrei

http://youtu.be/o5m0m_ZG9e8

On Monday, 14 July 2014 at 18:17:25 UTC, Andrei Alexandrescu wrote:

I ported my Datasheet-To-Code C# program to D for redemption:  https://github.com/JinShil/stm32_datasheet_to_d.

This is my favorite DConf 2014 talk. I absolutely admire dedication Mike has pushed through many annoying issues through to the point he has prevailed :) Best proof of concept for D usage in embedded barebone world I have seen so far.

On 7/14/2014 12:32 PM, Dicebot wrote:
> This is my favorite DConf 2014 talk. I absolutely admire dedication Mike has
> pushed through many annoying issues through to the point he has prevailed :)
> Best proof of concept for D usage in embedded barebone world I have seen so far.

Post this on reddit!

Am Mon, 14 Jul 2014 11:17:26 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> http://www.reddit.com/r/programming/comments/2aoqov/dconf_2014_day_2_talk_7_tiny_ubiquitous_machines/
> 
> https://www.facebook.com/dlang.org/posts/884725944874421
> 
> https://twitter.com/D_Programming/status/488748669869780992
> 
> 
> Andrei

Nice talk!
I hope we'll see D on quadrocopters and similar devices soon ;-)

There are actually some cheap (15-30€) quadrocopters on ebay with a
reprogrammable Cortex M0:

http://www.mikrocontroller.net/topic/309185 (german)
http://www.mikrocontroller.net/articles/Hack-O-Copter (german)
http://www.rcgroups.com/forums/showthread.php?t=2174365
https://github.com/hackocopter (OSS firmware)

The talk was nice, and it's the chance I was waiting to ask a question to the speaker.

I've read a very nice paper (+ slides) about using some specialized but simple type system rules to make less bug-prone the bit-twiddling kind of code, "Bit-Level Types for High-Level Reasoning" by Ranjit Jhala, Rupak Majumdar:

http://goto.ucsd.edu/~rjhala/papers/bit_level_types_for_high_level_reasoning.html

I'd like to use those ideas in D, they are useful for low-level or embedded programming.

The D type system (and D syntax) seem enough to implement most of them without changes to the D language (or with small changes, but you can't tell before you have tried implementing them with the current language).

So are those things a good addition to Phobos for your kind of programming? (additions to the language can be discussed later).

Bye,
bearophile

> So are those things a good addition to Phobos for your kind of programming? (additions to the language can be discussed later).

You can look at the slides for a quicker overview, or you can ask me here for a summary, if necessary.

Bye,
bearophile

On Tuesday, 15 July 2014 at 18:47:28 UTC, bearophile wrote:
> The talk was nice, and it's the chance I was waiting to ask a question to the speaker.
>
> I've read a very nice paper (+ slides) about using some specialized but simple type system rules to make less bug-prone the bit-twiddling kind of code, "Bit-Level Types for High-Level Reasoning" by Ranjit Jhala, Rupak Majumdar:
>
> http://goto.ucsd.edu/~rjhala/papers/bit_level_types_for_high_level_reasoning.html
>
> I'd like to use those ideas in D, they are useful for low-level or embedded programming.
>
> The D type system (and D syntax) seem enough to implement most of them without changes to the D language (or with small changes, but you can't tell before you have tried implementing them with the current language).
>
> So are those things a good addition to Phobos for your kind of programming? (additions to the language can be discussed later).
>
> Bye,
> bearophile

You may have to summarize it for me, because in my few minutes of scanning the slides and the PDF, I don't see much difference between what the authors are proposing and what's provided by std.bitmanip. (But the paper is pretty researchy, and its hard to see the forest through the trees).

I use absolute indexes in my code rather than bitwitdhs.  I do this because my datasheet uses absolute indexes, and it's important for me to be able to cross-reference to my datasheet, at a glance.  This is why I didn't use std.bitmanip.

My other goal is to enforce mutability and access.  I want to make sure I, or my users, know, at compile time, when they are trying to write to a read-only bitfield or otherwise access a bitfield incorrectly.

And finally, I want to reduce code size and increase performance.  I don't want to do read-modify-write if I don't have to, not just for threading concerns, but because that usually results in more instructions which is detrimental to both code-size and performance.  And, for the same reason, I don't want function-call overhead.

Anything that helps me achieve these goals is great.  D's CTFE, templates, and mixins really came through for me here.

My registers are modeled like this (enabled by my mmio.d - https://github.com/JinShil/memory_mapped_io/blob/master/source/mmio.d):

final abstract class RCC : Peripheral!(0x00003800)
{
    final abstract class CR : Register!(0x00, Access.Byte_HalfWord_Word)
    {
        alias PLLI2SRDY = Bit!(27, Mutability.r);
        alias PLLI2SON  = Bit!(26, Mutability.rw);
        alias PLLRDY    = Bit!(25, Mutability.r);
        alias PLLON     = Bit!(24, Mutability.rw);
        alias CSSON     = Bit!(19, Mutability.rw);
        alias HSEBYP    = Bit!(18, Mutability.rw);
        alias HSERDY    = Bit!(17, Mutability.r);
        alias HSEON     = Bit!(16, Mutability.rw);
        alias HSICAL    = BitField!(15, 8, Mutability.r);
        alias HSITRIM   = BitField!(7, 3, Mutability.rw);
        alias HSIRDY    = Bit!(1, Mutability.r);
        alias HSION     = Bit!(0, Mutability.rw);
    }
}

... and are used like this:

if (RCC.CR.HSIRDY)
{
    RCC.CR.HSION = true;
    while(!RCC.CR.HSIRDY);
}

This provides me a high-level abstraction to my bit manipulations, named fields, no overhead, and compile-time enforcement of constraints.

What in the authors' proposal is different than what is offered by std.bitmanip, and how could I leverage it to achieve the goals stated here?

Mike