4 ms·

This sort of thing is why I prefer to leave the C standard library out of my microcontroller code altogether. It keeps me from having to worry about what PC-cen

This sort of thing is why I prefer to leave the C standard library out of my microcontroller code altogether. It keeps me from having to worry about what PC-centric assumptions they may be making under the hood, and they're often a bit bloated anyway. Something you do have to watch out for regardless is accidental promotions of floats to doubles. C loves float promotion, and if you're not careful (and don't use the special compiler options) it's easy to turn a one-cycle FPU operation into a hundred-cycle CPU function call. I keep thinking there ought to be a better language for bare-metal microcontroller programming, but the demand for it is so small I'm not sure who would bother supporting it.

SnowHill9902 5y ago
That’s more about the compiler than C.
- traes 5y ago
  My friend, the compilers are implementing that behavior based on the C standard, which is the literal definition of what C is. It's absolutely about C.
- chrisseaton 5y ago
  What do you think the compiler should be doing differently? Is there’s no FPU support then what is the alternative?
  - languageserver 5y ago
    it is one of the unfortunate things about C, a language I love and defend dearly, is that on one hand it makes few assumptions about the system and is "bare metal" enough to shoot yourself, but at the same time it makes no assumptions about what is now agiven on modern systems
legalcorrection 5y ago
You probably know, but for the benefit of the others, at least some compilers support warning for that with -Wdouble-promotion.
- markrages 5y ago
  After about the fourteenth time I accidentally blew my timing and size budgets with double-precision softfloat routines, I learned of -Werror=double-promotion.
_vdpp 5y ago
Ada fits the bill well here, with zero-footprint runtimes available and also a tool for statically determining the stack size at compile-time: https://www.adacore.com/gnatpro/toolsuite/gnatstack https://www.adacore.com/gnatpro/toolsuite/gnatstack
- azinman2 5y ago
  Is there an OSS version of such a tool? I’d love to see Ada get “modernized” where the syntax could fundamentally change but the ideas are similar. Being able to explicitly say the range of values is pretty cool, for example.
  - _vdpp 5y ago
    One of the more experienced embedded Ada devs out there wrote this: https://github.com/simonjwright/stack_usage https://github.com/simonjwright/stack_usage I’m not sure if it would meet your requirements or not.
  - _vdpp 5y ago
    Ada syntax takes a little while to get used to, but replace {} with begin/end and it otherwise feels like any other procedural language out there. This is one of the better intros: http://cowlark.com/2014-04-27-ada/index.html http://cowlark.com/2014-04-27-ada/index.html One of my favorite lesser-advertised features is the ability to return arbitrary-length arrays or sum types from functions without heap allocation due to the use of a secondary stack.
nicoburns 5y ago
Have you looked at Rust? The Rust embedded ecosystem is still a bit immature, but there is whole ecosystem of std-lib free libraries - some specific to hardware, others generic implementations of useful functionality.
- jcranberry 5y ago
  Is Rust good for embedded? I thought the binaries they produced were too fat?
  - TingPing 5y ago
    Embedded is a wide field. It's young but has promise.
  - SAI_Peregrinus 5y ago
    It statically links. But bare-metal embedded generally doesn't support dynamic linking at all, so that's not a real problem there. A lot of the rest of the fat is from things like debugging symbols bounds checks that aren't included when building in release mode.
  - nicoburns 5y ago
    The extra fat in Rust binaries compiled with default settings is things like: - the standard library - jemalloc (this is no longer the default, but is still a factor in people's perception about binary size because it used to be) - debug symbols - unwinding support for panics All of these can be turned off for use cases like embedded where binary size is important and you'll then get binaries of comparable size to those produced by C compilers.
  - steveklabnik 5y ago
    You just have to pay attention. I work in Rust on embedded, it’s not a problem. The smallest x86_64 binary rustc has ever produced is like, 145 bytes. I’m on Arm, we have space for a lot more, but still actively try to keep sizes down. Some tasks in our system are ~500 bytes, the larger ones are on the order of 10k. You can’t just use the broader ecosystem willy nilly, and if you want truly small stuff, you have to know how to coax the compiler from time to time. But that’s just always going to be the case.

SnowHill9902 5y ago

That’s more about the compiler than C.

traes 5y ago
My friend, the compilers are implementing that behavior based on the C standard, which is the literal definition of what C is. It's absolutely about C.
chrisseaton 5y ago
What do you think the compiler should be doing differently? Is there’s no FPU support then what is the alternative?
- languageserver 5y ago
  it is one of the unfortunate things about C, a language I love and defend dearly, is that on one hand it makes few assumptions about the system and is "bare metal" enough to shoot yourself, but at the same time it makes no assumptions about what is now agiven on modern systems

legalcorrection 5y ago

You probably know, but for the benefit of the others, at least some compilers support warning for that with -Wdouble-promotion.

markrages 5y ago
After about the fourteenth time I accidentally blew my timing and size budgets with double-precision softfloat routines, I learned of -Werror=double-promotion.

_vdpp 5y ago

Ada fits the bill well here, with zero-footprint runtimes available and also a tool for statically determining the stack size at compile-time: https://www.adacore.com/gnatpro/toolsuite/gnatstack https://www.adacore.com/gnatpro/toolsuite/gnatstack

azinman2 5y ago
Is there an OSS version of such a tool? I’d love to see Ada get “modernized” where the syntax could fundamentally change but the ideas are similar. Being able to explicitly say the range of values is pretty cool, for example.
- _vdpp 5y ago
  One of the more experienced embedded Ada devs out there wrote this: https://github.com/simonjwright/stack_usage https://github.com/simonjwright/stack_usage I’m not sure if it would meet your requirements or not.
- _vdpp 5y ago
  Ada syntax takes a little while to get used to, but replace {} with begin/end and it otherwise feels like any other procedural language out there. This is one of the better intros: http://cowlark.com/2014-04-27-ada/index.html http://cowlark.com/2014-04-27-ada/index.html One of my favorite lesser-advertised features is the ability to return arbitrary-length arrays or sum types from functions without heap allocation due to the use of a secondary stack.

nicoburns 5y ago

Have you looked at Rust? The Rust embedded ecosystem is still a bit immature, but there is whole ecosystem of std-lib free libraries - some specific to hardware, others generic implementations of useful functionality.

jcranberry 5y ago
Is Rust good for embedded? I thought the binaries they produced were too fat?
- TingPing 5y ago
  Embedded is a wide field. It's young but has promise.
- SAI_Peregrinus 5y ago
  It statically links. But bare-metal embedded generally doesn't support dynamic linking at all, so that's not a real problem there. A lot of the rest of the fat is from things like debugging symbols bounds checks that aren't included when building in release mode.
- nicoburns 5y ago
  The extra fat in Rust binaries compiled with default settings is things like: - the standard library - jemalloc (this is no longer the default, but is still a factor in people's perception about binary size because it used to be) - debug symbols - unwinding support for panics All of these can be turned off for use cases like embedded where binary size is important and you'll then get binaries of comparable size to those produced by C compilers.
- steveklabnik 5y ago
  You just have to pay attention. I work in Rust on embedded, it’s not a problem. The smallest x86_64 binary rustc has ever produced is like, 145 bytes. I’m on Arm, we have space for a lot more, but still actively try to keep sizes down. Some tasks in our system are ~500 bytes, the larger ones are on the order of 10k. You can’t just use the broader ecosystem willy nilly, and if you want truly small stuff, you have to know how to coax the compiler from time to time. But that’s just always going to be the case.