6 ms·

So do I understand it correctly that you are saying the OP's code (or e.g. the one like in AceJohnny2) is not guaranteed to work correctly according to C89? Any

by stinos 8y ago

So do I understand it correctly that you are saying the OP's code (or e.g. the one like in AceJohnny2) is not guaranteed to work correctly according to C89? Any idea about C99?

Gibbon1 8y ago
My thoughts Probably will work with a specific compiler. If it fails it'll likely fall on it's face fail. Which with embedded is the best type of failure. Also you probably can force the behavior you need with pragma's (not portable) Portability is usually completely unimportant in embedded. C89 just don't. C++ in embedded. Lord god no, if you want to do that use rust instead. Or embedded python or lua, anything but C++.
- pjmlp 8y ago
  > C++ in embedded. Lord god no, if you want to do that use rust instead. Or embedded python or lua, anything but C++. First Rust needs to reach C++'s tooling maturity on embedded space. When there is High Integrity Rust certification, compiler backends for all major CPUs, SDK support on OSes like INTEGRITY or Mbed, UI embedded tooling for IoT displays, maybe we can start seeing production code there.
  - Gibbon1 8y ago
    > First Rust needs to reach C++'s tooling maturity on embedded space. Yeah and that's soon. Anyone starting an embedded project in C++ is making a grave mistake. > Mbed Those guys make a bad mistake and will pay for it.
    - pjmlp 8y ago
      Touching C is an even bigger one. It took C++ about 20 years to reach maturity in this space, with help of several OS and compiler vendors. You might be willing to bet the house on Rust, most business aren't, not in the current state of its toolchain. In 10 years from now, yeah I can clearly see it.
      - v_lisivka 8y ago
        I use Rust for embedded right now. Part of project is in C, part is in C++, part is in Rust. NRF52 and i.MX6. Can you point me to the problem with Rust or toolchain, which I missed, so I will be aware? Thank you in advance.
        pjmlp 8y ago
        Some ideas: - LLVM backend is limited regarding the supported CPU architectures; - Rust compiler is not certified for high integrity domains, where human lives might be endangered; - Features like SIMD are still nightly - Lack of integration with closed source toolchains from OEMs for mixed debugging and other development workflows, e.g. Keil, Microchip These issues might be complete irrelevant, or showstoppers, depending on the company.
        steveklabnik 8y ago
        SIMD is stable in five weeks, incidentally.
        pjmlp 8y ago
        From what I understood it is just phase I from SIMD support, right?
        steveklabnik 8y ago
        Yes, but also the most foundational part. There’s already high level libraries written on top.
        pjmlp 8y ago
        Thanks, will have a look into it.
        steveklabnik 8y ago
    - InitialLastName 8y ago
      Curiosity: What's the issue with Mbed? I've toyed with it; it seems nice enough, and is good for getting working code close to the metal without much development time. I'm very interested in what pitfalls come from using it.
- stinos 8y ago
  C++ in embedded. Lord god no Note so sure, maybe depends on what 'embedded' exactly means to you. I mean, years ago I was working on some TI C6x series DSPs and needed a circular buffer. Hadn't one in C, did have a templated one in C++. Didn't think twice: if the compiler would swallow it, and it did, why would I go through the hassle of doing the work again in C possibly beeding different implementations for different type or a bunch of rather ugly void* stuff? Everything worked out. So for that particual case, C++ in embedded, god yes, as it meant: less development time, reuse existing implementation both for float and int types, etc. And that's +10 years ago so I'd imagine there's now more compilers which would do it.
alxlaz 8y ago
Essentially yes. It's the same in C99, too. There's a bit of nuance here though. The function that the author chose to reimplement provides the platform-specific implementation of a function that's actually specified as part of CMSIS (https://developer.arm.com/embedded/cmsis https://developer.arm.com/embedded/cmsis). Its portability across cores and MCUs is not much of an issue, and you're usually tied to the compilers in this sort of projects, too. So it's not necessarily a bad idea from a purely technical standpoint. That being said: - No one who writes embedded software for a living expects to see bitfields in their source tree. In fact, there are standards that this code would break (e.g. in CERT C: https://wiki.sei.cmu.edu/confluence/display/c/EXP11-C.+Do+not+make+assumptions+regarding+the+layout+of+structures+with+bit-fields https://wiki.sei.cmu.edu/confluence/display/c/EXP11-C.+Do+no... ), so it wouldn't even get well through code review. It's a bad idea to surprise your coworkers :-). - Implementation-defined behaviour can sometimes be surprising and non-uniform. More often than not, the distinction between "bug" and "implementation-specific" is very blurry, and the corner cases are very hard to catch. You may think you're OK because your code doesn't need to be portable and it works fine on your device, but then it turns out the memory alignment of bit fields varies with field size because of course it does. - Precisely because of their infrequent use, the implementation of bit fields is one of the things that vendors often get wrong in early versions of a toolchain. At best, it's just a matter of inefficient access. At worst, it's bugs. And if you think that can't possibly go wrong, let me tell you about that time when an early version of msp430-gcc translated access to volatile variables into a NOP. (Disclaimer: that was a long time ago, on an early port. The MSP430 port of GCC is actually very solid.) So basically, just don't. Don't. There are well-known idioms for bit access. They are not readable as in "someone who knows English can read those programs just fine" but it takes like two minutes to understand those idioms. They are very readable, as in "anyone who's ever made a LED blink understands them". Yes, it's domain-specific knowledge, but you're already twiddling bits on tiny machines in a language that's not English. You're already full of domain-specific knowledge. Edit: ah -- just to make sure this doesn't get interpreted the wrong way. IMHO, C++ in embedded systems is not a bad idea. I don't use it because I've never worked on a project where I needed it, and therefore I never got the chance to be proficient with it. But I've seen solid, reliable devices running (what, to my untrained eye, seemed like) very clean, debugable C++ code. Also, "embedded" refers primarily to purpose, not platform capabilities. There are plenty of embedded platforms running on eight-core Xeons and state-of-the-art DSPs and whatnot. It's not all tiny MCUs with 4K of RAM and no MMU.

by stinos 8y ago

So do I understand it correctly that you are saying the OP's code (or e.g. the one like in AceJohnny2) is not guaranteed to work correctly according to C89? Any idea about C99?

Gibbon1 8y ago

My thoughts Probably will work with a specific compiler. If it fails it'll likely fall on it's face fail. Which with embedded is the best type of failure. Also you probably can force the behavior you need with pragma's (not portable) Portability is usually completely unimportant in embedded. C89 just don't. C++ in embedded. Lord god no, if you want to do that use rust instead. Or embedded python or lua, anything but C++.

pjmlp 8y ago
> C++ in embedded. Lord god no, if you want to do that use rust instead. Or embedded python or lua, anything but C++. First Rust needs to reach C++'s tooling maturity on embedded space. When there is High Integrity Rust certification, compiler backends for all major CPUs, SDK support on OSes like INTEGRITY or Mbed, UI embedded tooling for IoT displays, maybe we can start seeing production code there.
- Gibbon1 8y ago
  > First Rust needs to reach C++'s tooling maturity on embedded space. Yeah and that's soon. Anyone starting an embedded project in C++ is making a grave mistake. > Mbed Those guys make a bad mistake and will pay for it.
  - pjmlp 8y ago
    Touching C is an even bigger one. It took C++ about 20 years to reach maturity in this space, with help of several OS and compiler vendors. You might be willing to bet the house on Rust, most business aren't, not in the current state of its toolchain. In 10 years from now, yeah I can clearly see it.
    - v_lisivka 8y ago
      I use Rust for embedded right now. Part of project is in C, part is in C++, part is in Rust. NRF52 and i.MX6. Can you point me to the problem with Rust or toolchain, which I missed, so I will be aware? Thank you in advance.
      - pjmlp 8y ago
        Some ideas: - LLVM backend is limited regarding the supported CPU architectures; - Rust compiler is not certified for high integrity domains, where human lives might be endangered; - Features like SIMD are still nightly - Lack of integration with closed source toolchains from OEMs for mixed debugging and other development workflows, e.g. Keil, Microchip These issues might be complete irrelevant, or showstoppers, depending on the company.
        steveklabnik 8y ago
        SIMD is stable in five weeks, incidentally.
        pjmlp 8y ago
        From what I understood it is just phase I from SIMD support, right?
        steveklabnik 8y ago
        Yes, but also the most foundational part. There’s already high level libraries written on top.
        pjmlp 8y ago
        Thanks, will have a look into it.
        steveklabnik 8y ago
  - InitialLastName 8y ago
    Curiosity: What's the issue with Mbed? I've toyed with it; it seems nice enough, and is good for getting working code close to the metal without much development time. I'm very interested in what pitfalls come from using it.
stinos 8y ago
C++ in embedded. Lord god no Note so sure, maybe depends on what 'embedded' exactly means to you. I mean, years ago I was working on some TI C6x series DSPs and needed a circular buffer. Hadn't one in C, did have a templated one in C++. Didn't think twice: if the compiler would swallow it, and it did, why would I go through the hassle of doing the work again in C possibly beeding different implementations for different type or a bunch of rather ugly void* stuff? Everything worked out. So for that particual case, C++ in embedded, god yes, as it meant: less development time, reuse existing implementation both for float and int types, etc. And that's +10 years ago so I'd imagine there's now more compilers which would do it.

alxlaz 8y ago

Essentially yes. It's the same in C99, too. There's a bit of nuance here though. The function that the author chose to reimplement provides the platform-specific implementation of a function that's actually specified as part of CMSIS (https://developer.arm.com/embedded/cmsis https://developer.arm.com/embedded/cmsis). Its portability across cores and MCUs is not much of an issue, and you're usually tied to the compilers in this sort of projects, too. So it's not necessarily a bad idea from a purely technical standpoint. That being said: - No one who writes embedded software for a living expects to see bitfields in their source tree. In fact, there are standards that this code would break (e.g. in CERT C: https://wiki.sei.cmu.edu/confluence/display/c/EXP11-C.+Do+not+make+assumptions+regarding+the+layout+of+structures+with+bit-fields https://wiki.sei.cmu.edu/confluence/display/c/EXP11-C.+Do+no... ), so it wouldn't even get well through code review. It's a bad idea to surprise your coworkers :-). - Implementation-defined behaviour can sometimes be surprising and non-uniform. More often than not, the distinction between "bug" and "implementation-specific" is very blurry, and the corner cases are very hard to catch. You may think you're OK because your code doesn't need to be portable and it works fine on your device, but then it turns out the memory alignment of bit fields varies with field size because of course it does. - Precisely because of their infrequent use, the implementation of bit fields is one of the things that vendors often get wrong in early versions of a toolchain. At best, it's just a matter of inefficient access. At worst, it's bugs. And if you think that can't possibly go wrong, let me tell you about that time when an early version of msp430-gcc translated access to volatile variables into a NOP. (Disclaimer: that was a long time ago, on an early port. The MSP430 port of GCC is actually very solid.) So basically, just don't. Don't. There are well-known idioms for bit access. They are not readable as in "someone who knows English can read those programs just fine" but it takes like two minutes to understand those idioms. They are very readable, as in "anyone who's ever made a LED blink understands them". Yes, it's domain-specific knowledge, but you're already twiddling bits on tiny machines in a language that's not English. You're already full of domain-specific knowledge. Edit: ah -- just to make sure this doesn't get interpreted the wrong way. IMHO, C++ in embedded systems is not a bad idea. I don't use it because I've never worked on a project where I needed it, and therefore I never got the chance to be proficient with it. But I've seen solid, reliable devices running (what, to my untrained eye, seemed like) very clean, debugable C++ code. Also, "embedded" refers primarily to purpose, not platform capabilities. There are plenty of embedded platforms running on eight-core Xeons and state-of-the-art DSPs and whatnot. It's not all tiny MCUs with 4K of RAM and no MMU.