Re:The Embedded Rust Book
by burfog on Thursday May 02, 2019 @01:56PM
(#19810574)
I've done C firmware. I disagree about these problems.
C did not have a rigorously and formally defined memory model until 2011. We did C for almost 40 years before we got that.
Go read what Linus Torvalds has to say about "volatile", and then go rip it out of all your code. You should not be using that keyword, except possibly for a software-incremented global clock tick counter residing in normal RAM.
You need to call a function that will properly perform any required memory fences. If you don't do this, the CPU or bridges may reorder the memory accesses.
Rust might have problems, but the issues listed are not problems. My immediate concern is the availability of inline assembly. I would hope that this is possible and can be inlined into code that isn't marked unsafe.
C did not have a rigorously and formally defined memory model until 2011. We did C for almost 40 years before we got that.
Go read what Linus Torvalds has to say about "volatile", and then go rip it out of all your code. You should not be using that keyword, except possibly for a software-incremented global clock tick counter residing in normal RAM.
You need to call a function that will properly perform any required memory fences. If you don't do this, the CPU or bridges may reorder the memory accesses.
Rust might have problems, but the issues listed are not problems. My immediate concern is the availability of inline assembly. I would hope that this is possible and can be inlined into code that isn't marked unsafe.