5 ms·

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

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.

ErikCorry 4y ago
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.
- nine_k 4y ago
  While at it, I should mention Zig.
  - ErikCorry 4y ago
    Does zig have as a selling point that it has _more_ UB than C?
  - dleslie 4y ago
    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.
    - messe 4y ago
      > AFAICT, Zig is halfway step between C and C++ for desktop and mobile developers. What does this even mean? Zig very much has embedded use as a target as well, with freestanding use being a first-class citizen. The majority of the standard library works without an OS (and if you wish, you can provide your own OS-like interfaces quite easily, and use the OS-dependent parts in a freestanding environment). I've written a UEFI bootloader in Zig, and right now I'm using it on an RP2040 as well, cross compiling from an M1 Mac without the need to install any additional cross compilers. I'd argue that it might be even better for embedded than C/C++ eventually, as unlike them, allocation is even more tightly controlled, with a convention that only functions (or datastructures) that take an allocator as an argument will allocate memory on the heap. Future versions may even restrict recursion in certain contexts to guarantee max stack depths.
      - dleslie 4y ago
        Cool, you've targeted ARM on a common SoC and a desktop PC. Now do sh2, sh4, m68k or even xtensa with Zig with a standard build. They chose to build Zig on top of the worst compiler backend toolchain for embedded support.
        messe 4y ago
        Man, it hasn’t even fucking reached 1.0 yet. The fact that the default install can target multiple architectures (including C dependencies) is nothing short of impressive. Does GCC target any of those in its standard build? Oh. Wait. It doesn’t. It builds for only one architecture at a time and if you want anything else you’ll need to recompile the compiler. LLVM is even intended to be optional in future, and the Zig team is well on their way to making that a reality with the work on stage2. What backend would you suggest for embedded support?
        dleslie 4y ago
        Zig is 6 years old, and years-old issues exist in their task tracker requesting support for some of these targets. You _cannot_ simply recompile LLVM to support the targets I listed without using unsupported, risky patches from community sources; if any such patches exist. The multiple architecture support in one binary is a pointless feature when installing multiple GCC builds only takes a tiny, insignificant fraction of my development machine's disk space. Never in my life have I thought "Wow, I'd really speed up development if GCC was one enormous binary holding all possible targets." Zig's best path forward is to support targeting C as a first tier target; which they seem to be interested in doing.
mastax 4y ago
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.
- quelsolaar 4y ago
  "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.
  - ErikCorry 4y ago
    What is the relevance of RiscV here? Not weird at all. I feel like you skipped part of the argument.
    - gumby 4y ago
      The point is that new exploration of the design space only works when there’s a familiar environment to build on. The old days of each architecture being its own hermetic environment are gone.
    - saagarjha 4y ago
      Ok here’s a concrete one, ARM is experimenting with a brand new CHERI implementation that throws out a lot of “obvious” things that are supposed to be true for pointers and integers. The only way this has been able to work is that the standard is flexible enough to let C(++) work here. Rust is getting breaking changes to support the platform.
chrisseaton 4y ago
> 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.
- quelsolaar 4y ago
  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.
  - kevin_thibedeau 4y ago
    VLAs are optional since C11. There is no reason why a vendor can't support a modern language.
    - saagarjha 4y ago
      VLAs are not the only thing added to C since 1999.
      - morelisp 4y ago
        They are one of the few things added that require the target platform, rather than the compiler, to do something different. (And the other big things like that, like atomics, are similarly optional.)
duped 4y ago
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.
- astrange 4y ago
  LLVM IR isn’t stable or even portable. It’s just a compiler IR, not a language.
  - duped 4y ago
    Hence the qualifier, if it focused on stability. And IRs are languages. They look and quack like them and people treat them as such.
    - saagarjha 4y ago
      And pay the price, there are tons of places that are stuck with some ossified “LLVM 3.2” toolchain or similar because they build their stuff on an unstable IR.
      - duped 4y ago
        Yea and again, I said "if". We live on the else branch of that if statement. My point is that a lot of this sentiment is treating C as the portable backend of a compiler because there is no portable front end. It holds us back in a lot of ways from iterating on systems languages in ways that are interesting and valuable. Ideally there would be an IR with stable textual and binary format that can be compiled into the machine code for various ISAs and support the extensions necessary by silicon manufacturers for the exotic bits. I've used exotic tool chains for weird ISAs where the exotic bits are sugar added to a GCC front end, and it always feels wrong and limiting.

ErikCorry 4y ago

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.

nine_k 4y ago
While at it, I should mention Zig.
- ErikCorry 4y ago
  Does zig have as a selling point that it has _more_ UB than C?
- dleslie 4y ago
  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.
  - messe 4y ago
    > AFAICT, Zig is halfway step between C and C++ for desktop and mobile developers. What does this even mean? Zig very much has embedded use as a target as well, with freestanding use being a first-class citizen. The majority of the standard library works without an OS (and if you wish, you can provide your own OS-like interfaces quite easily, and use the OS-dependent parts in a freestanding environment). I've written a UEFI bootloader in Zig, and right now I'm using it on an RP2040 as well, cross compiling from an M1 Mac without the need to install any additional cross compilers. I'd argue that it might be even better for embedded than C/C++ eventually, as unlike them, allocation is even more tightly controlled, with a convention that only functions (or datastructures) that take an allocator as an argument will allocate memory on the heap. Future versions may even restrict recursion in certain contexts to guarantee max stack depths.
    - dleslie 4y ago
      Cool, you've targeted ARM on a common SoC and a desktop PC. Now do sh2, sh4, m68k or even xtensa with Zig with a standard build. They chose to build Zig on top of the worst compiler backend toolchain for embedded support.
      - messe 4y ago
        Man, it hasn’t even fucking reached 1.0 yet. The fact that the default install can target multiple architectures (including C dependencies) is nothing short of impressive. Does GCC target any of those in its standard build? Oh. Wait. It doesn’t. It builds for only one architecture at a time and if you want anything else you’ll need to recompile the compiler. LLVM is even intended to be optional in future, and the Zig team is well on their way to making that a reality with the work on stage2. What backend would you suggest for embedded support?
        dleslie 4y ago
        Zig is 6 years old, and years-old issues exist in their task tracker requesting support for some of these targets. You _cannot_ simply recompile LLVM to support the targets I listed without using unsupported, risky patches from community sources; if any such patches exist. The multiple architecture support in one binary is a pointless feature when installing multiple GCC builds only takes a tiny, insignificant fraction of my development machine's disk space. Never in my life have I thought "Wow, I'd really speed up development if GCC was one enormous binary holding all possible targets." Zig's best path forward is to support targeting C as a first tier target; which they seem to be interested in doing.

mastax 4y ago

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.

quelsolaar 4y ago
"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.
- ErikCorry 4y ago
  What is the relevance of RiscV here? Not weird at all. I feel like you skipped part of the argument.
  - gumby 4y ago
    The point is that new exploration of the design space only works when there’s a familiar environment to build on. The old days of each architecture being its own hermetic environment are gone.
  - saagarjha 4y ago
    Ok here’s a concrete one, ARM is experimenting with a brand new CHERI implementation that throws out a lot of “obvious” things that are supposed to be true for pointers and integers. The only way this has been able to work is that the standard is flexible enough to let C(++) work here. Rust is getting breaking changes to support the platform.

chrisseaton 4y ago

> 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.

quelsolaar 4y ago
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.
- kevin_thibedeau 4y ago
  VLAs are optional since C11. There is no reason why a vendor can't support a modern language.
  - saagarjha 4y ago
    VLAs are not the only thing added to C since 1999.
    - morelisp 4y ago
      They are one of the few things added that require the target platform, rather than the compiler, to do something different. (And the other big things like that, like atomics, are similarly optional.)

duped 4y ago

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.

astrange 4y ago
LLVM IR isn’t stable or even portable. It’s just a compiler IR, not a language.
- duped 4y ago
  Hence the qualifier, if it focused on stability. And IRs are languages. They look and quack like them and people treat them as such.
  - saagarjha 4y ago
    And pay the price, there are tons of places that are stuck with some ossified “LLVM 3.2” toolchain or similar because they build their stuff on an unstable IR.
    - duped 4y ago
      Yea and again, I said "if". We live on the else branch of that if statement. My point is that a lot of this sentiment is treating C as the portable backend of a compiler because there is no portable front end. It holds us back in a lot of ways from iterating on systems languages in ways that are interesting and valuable. Ideally there would be an IR with stable textual and binary format that can be compiled into the machine code for various ISAs and support the extensions necessary by silicon manufacturers for the exotic bits. I've used exotic tool chains for weird ISAs where the exotic bits are sugar added to a GCC front end, and it always feels wrong and limiting.