Hacker News Reader

Comment by AdamH12113 | Hacker News Reader

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.

View on HN

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

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.

One of the more experienced embedded Ada devs out there wrote this: https://github.com/simonjwright/stack_usage

I’m not sure if it would meet your requirements or not.

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

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.

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

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

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.

Is Rust good for embedded? I thought the binaries they produced were too fat?

Embedded is a wide field. It's young but has promise.

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.

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.

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.

And while the headline features of Rust are memory safety and fearless concurrency, the whole language and ecosystem is designed around making it hard to do the wrong thing on accident.

Which in this instance also means that floats stay floats, doubles stay doubles and u8 stays u8 unless you explicitly convert. If you're now asking what happens when you add a float to a double: that's a compiler error, you have to explicitly cast.

That’s more about the compiler than C.

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.

What do you think the compiler should be doing differently? Is there’s no FPU support then what is the alternative?

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

Reply on news.ycombinator.com