Comment by quelsolaar
3 years ago
It doesn't have to be C, but as of today there is no other option. No one is coming up with new languages with these kinds of features so C it is. People should, but language designers today are more interested in memory safety and clever syntax, than portability.
I would like to caution you against thinking that these weird platforms are old machines from the 60s that only run in museums. For instance many DSPs have 32bit bytes (smallest memory unit that can be individually addressed), so if you have a pair of new fancy noise canceling headphones, then its not unlikely you are wearing a platform like that on your head everyday.
Unusual platforms like DSPs usually have specific (usually proprietary) toolchains. Why can't those platforms implement extensions to support 32-bit bytes? Why must everyone else support them? In practice ~no C code is portable to machines with 32-bit bytes. That's okay! You don't choose a DSP to run general purpose code. You choose it to run DSP code, usually written for a specific purpose, often in assembly.
"Weird" platforms often do have their own tool-chains but they do have the ability to leverage LLVM, MISRA, and an array of common tools and analyses that exists for C. One of the reason we got new platforms like RISC-V is that today its possible to use existing OSS software to build a platform with a working OS and Development environment, that common basic libraries can be built for is that all this software is written in C and can be targeted towards a new platform.
doesn't LLVM only cover a smidge of the weird platforms, if that?
Like, it doesn't even cover ESP32 chips, despite attempts to get support into LLVM since 2019.
point being, they can't leverage LLVM
What is the relevance of RiscV here? Not weird at all. I feel like you skipped part of the argument.
3 replies →
Because C already does this, and has from the beginning. C was designed to be portable in an era where there were significant differences in fundamental CPU design decisions between platforms. C is widely used to write software for all kinds of weird platforms. Changing that would be far more work than just making a new language.
They also tend to be non-standard for a variety of reasons anyway! C bends backwards to support odd architectures but is often also insufficient (or at least the vendors cannot justify the effort to achieve full compliance and their customers don't care significantly anyway).
Perhaps Carbon is the first in a series of new low level languages that free us from the impossible tensions of C/C++ having to be all things to all (low level) programmers.
I would love a new language for implementing high level languages. I've worked on several of these projects and we use mostly unstandardized dialects of C++ and it's really not fit for purpose.
While at it, I should mention Zig.
Does zig have as a selling point that it has _more_ UB than C?
AFAICT, Zig is halfway step between C and C++ for desktop and mobile developers.
I'm thrilled that the folks steering C are keeping the needs of embedded developers at the forefront.
4 replies →
> It doesn't have to be C, but as of today there is no other option
Isn’t C99 an option? Why can’t more advanced things go into newer C and people who genuinely need something more basic can use C99.
We can! Many of us still use c89.(c99 has problems, like variable length arrays).
The reality however is that you cant escape never versions entirely. Not all code you interact with was written in the subset you want, so when your favorite OS or library starts using header files with newer features you need to run that version of the language too.
Another less appreciated detail, is that a lot of WG14 work is not about adding new features but clarifying how existing features are meant to work. When the text is clarified this gets back-ported to all previous versions of C in major compilers. An example of this is "provenance". This is a concept that implicitly been standard since the first ISO standard, but only now is becoming formalized. This means that if you want to adhere to the C89 standard, you will find a lot of clarifications about how things should work in the C23 standard.
VLAs are optional since C11. There is no reason why a vendor can't support a modern language.
2 replies →
If it were to focus on stability, it would probably be LLVM IR. That said, there's plenty of C++ being written for these applications. And Ada.
> so if you have a pair of new fancy noise canceling headphones, then its not unlikely you are wearing a platform like that on your head everyday.
Chip shortage aside, the likelihood of these devices using obscure hardware like discrete DSPs is going down as cheaper low power architectures are becoming commoditized.
LLVM IR isn’t stable or even portable. It’s just a compiler IR, not a language.
Hence the qualifier, if it focused on stability. And IRs are languages. They look and quack like them and people treat them as such.
2 replies →