11 ms·

C ABI to the rescue! That may be the one thing left of C in 50 years' time.

• MaxBarraclough 8y ago
  A dead lingua franca, Like Latin. Could happen, but I suspect embedded programmers will stick with C forever.
  • kccqzy 8y ago
    This is one reason I don't really like embedded programming. There seems to be generally a fear of newer systems languages like Rust and a fear of newer features in C++. An embedded programmer told me he doesn't use the C++ STL because he doesn't want functions allocating stuff on his back. Doesn't seem very convincing as you can always redefine the global operator new.
    • kstenerud 8y ago
      It's not a problem of how things are allocated, but rather when. In an embedded environment, you need to be very aware of what is being used at any given time and how, and complex templates like in STL have a tendency to allocate and deallocate in ways that can be difficult to follow, or might have a worst case memory footprint that blows through your RAM.
      • foundry27 8y ago
        Not disagreeing with your point about STL classes having a tendency to make egregious allocations (heck, a lot of them are fundamentally designed around using allocators for pretty much everything), but the fact that they’re often complicated templates is totally orthogonal to that, and I think it’s disingenuous to say that there’s a causal relationship between the two. If anything, templating encourages statically-verifiable, compiler-enforced code invariants and outputs, which can be pretty darn nice for embedded.
    • rcxdude 8y ago
      There is a fair amount of interest in Rust from embedded programmers, though at the moment you can only really use it for ARM cores (which are probably among the most common embedded cores but there are a huge number of alternatives). There is a dedicated working group within the rust community for embedded which is pushing towards having a good user experience for those wanting to use Rust in such an environment. But even within embedded rust you won't find much appetite for dynamic memory allocation, and a fair amount of the work has been stabilizing the mechanisms by which you can build rust code which does not use its standard library ('no_std'). This has nothing to do with the fear of the new and lots to do with predictability of code. Using a single heap for all allocations is not at all ideal in an embedded context: your allocations become much harder to predict (both in terms of failure and in terms of time taken), errors become harder to recover from, and it becomes harder to reason about the amount of memory your system will use (especially in edge cases). For embedded work you will generally try very hard to allocate everything statically, and use some kind of pool allocation if you cannot (and often you combine the allocation and whatever datastructure you are placing the objects in).
      • josephg 8y ago
        > Using a single heap for all allocations is not at all ideal in an embedded context The same is true in game development. Using a per-frame arena allocator for short lived objects can make a big difference to performance. And Rust’s lifetime rules can be used to make this sort of thing completely safe. It’s a shame that rust std completely relies on the hidden global allocator instead of accepting an allocator as a parameter. It means that while you can write your arena allocator, you can’t use it with any of the built in Box/Vec/HashSet/etc types. I actually really like Zig’s answer here of just passing in an allocator as an argument in all data structures. I’d love to see that in rust!
        • steveklabnik 8y ago
          We didn’t have an allocator API, or we would have liked to. Global allocators have finally stabilized. Working on it!
    • rkangel 8y ago
      > There seems to be generally a fear of newer systems languages like Rust It's not fear of newer languages (most of the time). I would love to use Rust for embedded in a professional environment but it loses out quickly based on supported platforms. As leader of an embedded development team, I can't choose a language that will limit the processor parts we can use when we get closer to manufacturing and cost reduction. At volume, many millions spent on software development is dwarfed by cost savings from swapping in the right part.
      • oblio 8y ago
        I've always been curious about this, could you give more details? It would be interesting to know what a 8-bit chip costs vs a 32-bit one, for example.
        • rkangel 8y ago
          8 Bit chips tend be anywhere from 1 cent to $3 in volume. 32 bit chips are usually be from $1 to $20. It doesn't tend to be that extreme a part swap - if you're doing signal processing and UI then you're probably always going to use a 32 bit part. If you're just doing some basic logic with a couple of digital inputs then you're probably always going to use an 8 bit part. You might move 32 bit ARM to 16 bit MSP430 to hit a power budget or similar. Leaving aside processor architecture, the factors that affect cost from most to least (approx) are: Flash size, number of peripherals/features, clock speed, ram size. Basically, sometimes another manufacturer will have a part that meets your feature requirements much cheaper, and then you port the code. The rest of the time, you're just squeezing program space, memory usage and processor usage to reduce the required specs.
    • shaklee3 8y ago
      From what I recall, SpaceX doesn't allow any external libraries in their embedded rocket code.
  • pjmlp 8y ago
    Yeah, most of them are still on C89, even if the compilers do C11.
    • MaxBarraclough 8y ago
      Real C programmers use C89, huh.
• pjmlp 8y ago
  On modern OSes C ABI is largely irrelevant. ChromeOS, Android, Windows/UWP, Fuchsia, ... C ABI is a actually the OS ABI, when they happen to be written in C and expose syscalls in C. As for C in 50 years, it depends how much we keep on using UNIX.
  • usrusr 8y ago
    The parts of Android that don't use the C ABI are not an OS though.
    • pjmlp 8y ago
      Try to use that C ABI and see how far you go writing an Android application, an user space driver in Android Things, or a Treble driver.
  • int_19h 8y ago
    And how many of those are defined in terms of the underlying C ABI? For example, WinRT - used by Windows/UWP - can be expressed entirely in terms of C structs and function pointers.
    • pjmlp 8y ago
      By exploiting how Windows C++ compilers layout VMT tables. Yet this is much less relevant in UWP, which allows for richer type system. Additionally the COM/UWP ABI requires type libraries for properly accessing the objects and marshaling.
      • int_19h 8y ago
        COM is a C ABI first and foremost - somewhere in MSDN, there's actually a page that exactly specifies vtable layout. It's not really surprising that it's C++-compatible, given that it's the most obvious way to do a vtable when you have just a single base class. But yes, of course, Win32 C++ implementations would maintain that compatibility - you could consider it the C++ bindings to COM, in a sense. And yes, WinRT does require its metadata for marshaling (COM doesn't - you can compile proxies/stubs from IDL). It does not require that for accessing objects, and there are many WinRT components which, in fact, cannot be marshaled at all. But all that doesn't make it any less of a C ABI - the metadata format is documented, and the standard WinRT APIs used to access it are themselves WinRT-compliant, and therefore the whole thing can be consumed from C, if painfully.
• deleted 8y ago
  [deleted]
• Cyph0n 8y ago
  As someone who works on a large OS consisting of ~200m lines of C: I really don't think so.