Support for embedded targets

[bradleyharden]

Support for embedded targets

[eivindbergem]

I suffer from chronic over-engineering disorder, so I always jump straight to the more involved solutions 😛 Feature flags are probably good enough.

[bradleyharden]

@eivindbergem, FYI, apparently I complain quite loudly 😛, because that RFC linked above is now being merged. It entered final comment period just now.

[bradleyharden]

Actually, maybe there's a fairly straightforward solution. We could add two sets of nested features, e.g. (atomic_8, atomic_16, ...) and (atomic_cas_8, atomic_cas_16, ...). Turning on a 16 feature would imply 8, etc. The defaults would be atomic_64 and atomic_cas_64, but users could opt-in to lower values for a given target.

[bradleyharden]

I can confirm I'm able to get cargo check to run on thumbv7em with this approach (see WIP in #8).

Are you ok with this approach? Maybe I should assume atomic_cas_X implies atomic_X? That would simplify the features a bit.

[eivindbergem]

I also looked into this while working on #5. The ideal would be something that works just like target_has_atomic will when stabilized, but for that you would need to know the atomic support for each target, something I haven't been able to find in a structured form. I guess it's buried somewhere inside rustc, but my grep'ing failed to uncover it.

I did start exploring an alternative approach, trying to compile code using each Atomic struct for each platform and outputting a build script with the right compiler flags, but I got sidetracked. I guess this could be a separate crate that could be included as a build dependency to provide a target_has_atomic equivalent.

@bradleyharden If you're interested, I could pick up the thread on this and we could work out something together.

[bradleyharden]

Sure, having it done automatically would be nice. But I also think the feature flag approach would be an acceptable alternative. It's a one-time setup for users, and it also forces them to understand exactly what operations are available on their platform.

[bradleyharden]

I agree it's a better solution, just more complex. My only real argument against it is that it requires users to trust another dependency build script.

Either way is fine with me, though.

[bradleyharden]

After a recent refactor of my code, I no longer need this library. I do think it would be useful in embedded contexts, though, so I would still like to see this implemented. But since we haven't heard from @LukasKalbertodt yet, I'm going to drop this for now.

[bradleyharden]

@eivindbergem, one last comment. It looks like the heapless build script does something like what you're describing. Maybe you could look there for inspiration.

[eivindbergem]

@bradleyharden Finally some movement on that front, and it only took five years and a few complaints!

[LukasKalbertodt]

Hi there! Sorry that it took me so long to reply, but I was moving to a different city, which took a surprising amount of mental capacity for quite some time 😮

I was already subscribed to the target_has_atomic tracking issue since when I initially wrote this library. At one point I even used target_has_atomic behind a nightly feature flag. This is the commit that removed it: 069d70a. As the commit says, it was kind of a pain to maintain. Once those attributes are stable (which, if I'm understanding correctly should be in 1.60, releasing on April 7th), I am happy to reapply them everywhere they make sense. That would require a major version bump due to the MSRV bump, but I'm totally fine with that.

[bradleyharden]

Sounds good

[bradleyharden]

Well, it looks like they are rolling back target_has_atomic_load_store. I don't need it for thumbv7em, but it would be required for any atomig support on thumbv6m. That's frustrating.

[LukasKalbertodt]

I just released 0.4.0 which uses target_has_atomic in all appropriate places. This makes this crate usable on thumbv7em. But as the previous comment says, targets like thumbv6m still don't work well with atomig. To track the latter, I opened a new issue #10.