[RFC] Resources initialized at runtime

[japaric]

Motivation

In the current version of RTFM every resource must be assigned an initial value
at compile time and in const / static context. This requirement can sometimes be
too strict given the current limitations of const evaluation (no loops, no
conditionals, etc.).

In other cases one may want to initialize a resource according to the outcome of
the init function. For instance one may want to store the frequency of the
processor, product of the initialization routine, in a variable; in the current
system this requires the programmer to manually keep a copy of the value (as a
literal) in the resources section of the app! macro, which is error prone.

The workaround for these issues is to use an Option for the resource and to
select None as the initial value. Then a value can be assigned to the resource
resource in the init function. The downside of this approach is that it
requires the program to unwrap or match the Option value whenever they
want to access the resource data. And, of course, there's no compile time
guarantee that the programmer won't forget to actually initialize the Option
resource to some value in init; forgetting to do so would cause a panic! at
runtime.

Design

We make the initial value of resources optional in the app! macro:

app! {
    resources: {
        static BUFFER: [u8; 32] = [0; 32];
        static FREQUENCY: u32;
        static FOO: Vec<u8>;
    },
}

When the initial value of any resource is omitted the signature of init will
be changed to force the programmer to assign a value to these resources during
the initialization phase:

fn init(p: init::Peripherals, r: init::Resources) -> init::ResourceValues {
    // .. initialize stuff like the heap allocator ..

    // These are the initial values of the "uninitialized" resources
    init::ResourceValues {
        FREQUENCY: frequency,
        FOO: vec![a, b, c],
    }
}

Apart from this change in init there's no difference between using resources
with different initialization strategies.

What goes on under the hood?

Under the hood the resource without initial values will actually be static
variables with type equal to Option and initialized to None. However, since
we know that the resources will be initialized in init and before any task
(or idle) can run we can expose them to the user without the Option wrapper,
plus we can apply unsafe optimizations like intrinsics::unreachable under the
hood to eliminate branches and avoid unwrapping.

Possible extensions

Optimizing the pre-main initialization of static variables

Since the runtime initialized resources will be represented as static
variables containing an Option they'll still be initialized before init by
the runtime even though those initial values won't be read. This useless
initialization can be optimized away with the help of linker script magic:

// runtime initialized resources
#[link_section = ".uninit"]
static mut FREQUENCY: Option<u32> = None;

#[link_section = ".uninit"]
static mut FOO: Option<Vec<u8>> = None;

// "normal" resources
static mut BUFFER: [u8; 32] = [0; 32];

static variables placed in the .uninit linker section won't be initialized
before init. This may require changes in cortex-m-rt to ensure that static
variables placed in the .uninit section end up having a valid address in the
RAM region though. cf. rust-embedded/cortex-m-rt#32

cc @cr1901

[pftbest]

Under the hood the resource without initial values will actually be static
variables with type equal to Option and initialized to None.

Then it's not going to be a zero cost abstraction. Option<u32> is actually 8 bytes in size.
Too bad that mem::zeroed() is not a const fn.

[perlindgren]

Hi I have exactly the same problem when extending this approach to Concurrent Reactive Objects. I don’t think that the problem is mem::zeroed(), but rather the crippled const fn evaluation in today’s Rust. Lets hope that is solved soon (would make life in Rust much more pleasant). (We may even have mem::unintilized() in some cases, where the framework is guaranteed to fill in data. I have resorted to Option just to get around user having to give excessive and stupid init values. (Allthough it carries some memory and potentially run-time OH…, it is the least bad solution for now…) Best, Per On 24 Jul 2017, at 00:13, Vadzim Dambrouski <notifications@github.com<mailto:notifications@github.com>> wrote: Under the hood the resource without initial values will actually be static variables with type equal to Option and initialized to None. Then it's not going to be a zero cost abstraction. Option<u32> is actually 8 bytes in size. Too bad that mem::zeroed() is not a const fn. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://github.com/japaric/cortex-m-rtfm/issues/37#issuecomment-317286084>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AD5naPEWRlRdXlNXx-_CgS7MYk6SNhTjks5sQ8V2gaJpZM4OglGo>. {"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/japaric/cortex-m-rtfm","title":"japaric/cortex-m-rtfm","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/japaric/cortex-m-rtfm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@pftbest in #37: \u003e Under the hood the resource without initial values will actually be static\r\nvariables with type equal to Option and initialized to None.\r\n\r\nThen it's not going to be a zero cost abstraction. `Option\u003cu32\u003e` is actually 8 bytes in size.\r\nToo bad that `mem::zeroed()` is not a `const fn`."}],"action":{"name":"View Issue","url":"https://github.com/japaric/cortex-m-rtfm/issues/37#issuecomment-317286084"}}}

[japaric]

Did mem::size_of become a const fn yet? If yes then we could use static mut FOO: [u8; size_of::<T>()] = [0; size_of::<T>()]; and cast &[u8; size_of::<T>()] into &T behind the hood. And pray that nothing explodes ... as in hope that LLVM won't generate UB.

[pftbest]

[u8; size_of::()] may not have a correct alignment, unfortunately.

[perlindgren]

Hi This is tricky and delicate stuff. The lazy statics approach won’t help either unfortunately as far as I can tell. I think proper const fn eval in Rust is what we can hope for. Best, Per On 24 Jul 2017, at 00:35, Vadzim Dambrouski <notifications@github.com<mailto:notifications@github.com>> wrote: [u8; size_of::()] may not have a correct alignment, unfortunately. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<https://github.com/japaric/cortex-m-rtfm/issues/37#issuecomment-317287211>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AD5naIGgyoTldpwI7UHgAXUfy0ddBTApks5sQ8rOgaJpZM4OglGo>. {"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/japaric/cortex-m-rtfm","title":"japaric/cortex-m-rtfm","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/japaric/cortex-m-rtfm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@pftbest in #37: [u8; size_of::\u003cT\u003e()] may not have a correct alignment, unfortunately."}],"action":{"name":"View Issue","url":"https://github.com/japaric/cortex-m-rtfm/issues/37#issuecomment-317287211"}}}

[japaric]

@pftbest we can use ([u8; mem::size_of::<T>()], [T; 0]) then. See bellow:

#![feature(const_fn)]

use std::mem;

static mut FOO: ([u8; mem::size_of::<u64>()], [u64; 0]) =
    ([0; mem::size_of::<u64>()], []);

fn main() {
    unsafe {
        println!("{}", mem::align_of_val(&FOO));
        println!("{}", mem::size_of_val(&FOO));
    }
}

$ cargo run
8
8

[pftbest]

@japaric, this might work. LLVM doesn't have a strict aliasing rules like in C, so if the size and alignment match I don't see why it would fail (yet).

But still it's a very ugly hack. Maybe we can ask lang team to make mem::zeroed const, until CTFE lands?

[jonas-schievink]

👍 for this feature, it would be very useful to have!

Wouldn't it be possible to use a union for this? Something like this:

union LateResource {
    uninit: (),
    init: Foo,
}

// Resources:
static mut FOO: LateResource = LateResource { uninit: () };

And then after init was called:

let resource_values = init(...);
FOO = LateResource { init: resource_values.FOO };

[pftbest]

@jonas-schievink This is a great idea, thanks!

[jonas-schievink]

I'd like to give this a shot if no one is working on this yet :)