Hacker News new | ask | show | jobs
by svorakang 1177 days ago
Automotive embedded C developer here. Most of the code in this industry is implemented in a subset of ANSI C90. The reason is not header files, libraries or linker scripts. The reason is as the grandparent post points out: compiler availability.

For rare targets, there's just no money in making a compiler work for more than this small subset of C. My favorite example is the compiler for a really strange architecture where everything is 24 bits. Char is short is long is a pointer.

Bigger controllers tend to be ARM-based, so it's getting better.

Also Tricore has a big share, but their compiler support is getting better. There was even a rust compiler being announced recently, though I doubt it's using LLVM backend, so it's likely to be behind in terms of features.

3 comments

> Char is short is long is a pointer.

I thought char was required by the C standard to be 8 bits. If everything is 24 bits, how do you cover 24 bit address space with 8 bit pointers?

> I thought char was required by the C standard to be 8 bits

It's not. (EDIT: it is required to be at least 8 bits though)

Welcome to C! The guns are free, but you can only point them at your foot.

The C standard specifies so much less than everyone thinks.

It specifies so much less, precisely to allow it to be usable on such weird architectures.
I wouldn't really qualify this as a foot gun, but rather appropriate flexibility. 98% of people never encounter it, and the 2% that do are happy that it is that way, and I don't think alternative approaches like having the compiler hide it are appropriate for C.
I thought char was required by the C standard to be 8 bits

Common misconception.

to be at least 8 bits though

At least 8 bits for the latter-day compilers for which the 'standard' was the guide. I have seen C compilers where char was 6-bit or 7-bits matching the underlying hardware. However, those probably never implemented more than K&R or some pre-standardization perversion of it.

Also...as noted a char can be more than 8 bits, pre- and post-standardization. I've heard tell of (at least) 9-, 16-, 24- and 32-bit chars on more or less weird platforms.

At some point I'm sure the standards bodies will do some variation of depreciating 8-ish-bit char's for 32-bit Unicode as the standard representation for text.

My favorite example is the compiler for a really strange architecture where everything is 24 bits

DSP? That's the one example I can think of where 24-bit architectures are in active use (and many of them are not Von Neumann, but Harvard with separate data/program memory.)

> The reason is as the grandparent post points out: compiler availability.

is there no appetite to self-write a compiler for the architecture being used?