4 ms·

A couple of examples what's missing from C from a low level perspective: Multiple return values (why can't I have a function using more registers than rax or th

A couple of examples what's missing from C from a low level perspective: Multiple return values (why can't I have a function using more registers than rax or the stack to push back more values?), sane varargs, stack manipulation (an enabler for coroutines and a lot more) Generally, in an ideal low-level language I wouldn't expect to be hampered because the language is designed for a notional abstract machine that doesn't have things like an actual stack and contiguous RAM.

tialaramex 1mo ago
Also C isn't well suited to a modern multi-core computer. The "fix" in C11 is to just say we have the C++ 11 Memory Ordering Model and here are some built-ins for the ordered atomic operations that implies. Having any model at all is probably most of the value and only one part of the model (consume ordering) is unimplementable fantasy so it could have been much worse, but it's hardly a triumph for a "fundamental" language is it?
- inigyou 1mo ago
  What would you add to make it suitable? Large SIMD operations that the compiler could split across cores?
  - tialaramex 1mo ago
    I'm definitely the wrong person to ask because my solution was to write Rust. I think the machines C was conceived for are small enough by today's standards that I would not bring a high level language (like C) to the fight, a macro assembler and you'll be fine. For today's much larger machines, use Rust. Oh you've got 16-bit addressing? Chart all the addresses and what you'll use them for on a white board or a big sheet of paper. You do not need "allocators" like malloc, that's Steve's job, Steve has a sharpie to "allocate" memory on the chart.
    - inigyou 1mo ago
      Ironically I think to make the best use of such a small memory window, you'd want a compacting garbage collector. Lots of the 16-bit era BASICs used compacting GC for their strings. Yes you can statically allocate, but who wants an artificial limitation like "16 strings, 256 bytes each" when some users want 200 strings of 8 bytes and some users want 4 strings of 500 bytes. Static allocation is something you can do when your memory is large compared to your use cases.
- designuki 1mo ago
  > The "fix" in C11 is to just say we have the C++ 11 Memory Ordering Model and here are some built-ins for the ordered atomic operations that implies. Isn't Rust's solution mostly the same, just with C++20? https://doc.rust-lang.org/nomicon/atomics.html https://doc.rust-lang.org/nomicon/atomics.html > Rust pretty blatantly just inherits the memory model for atomics from C++20.
  - tialaramex 1mo ago
    Rust does have the same Memory Ordering idea (minus the ill-fated "Consume" ordering) but provides richer tools for a modern world than C does. The C standard library provides nothing to actually do concurrency, such as making more threads, nor to synchronize them, such as with a mutex whereas of course Rust provides std::thread::spawn and std::sync::Mutex In C this is a platform specific problem, for Unix systems you want pthreads for example while Windows provides a different arrangement. Rust does not provide out-of-the-box structured concurrency - which I would like - but it's a lot closer to what I'd prefer here.
    - fanf2 1mo ago
      The C standard library has had <threads.h> since C11 https://www.cppreference.com/c/thread https://www.cppreference.com/c/thread and there are now a nonzero number of systems that support it! (glibc, musl, maybe others?)
      - tialaramex 1mo ago
        Well TIL. Thanks.

tialaramex 1mo ago

Also C isn't well suited to a modern multi-core computer. The "fix" in C11 is to just say we have the C++ 11 Memory Ordering Model and here are some built-ins for the ordered atomic operations that implies. Having any model at all is probably most of the value and only one part of the model (consume ordering) is unimplementable fantasy so it could have been much worse, but it's hardly a triumph for a "fundamental" language is it?

inigyou 1mo ago
What would you add to make it suitable? Large SIMD operations that the compiler could split across cores?
- tialaramex 1mo ago
  I'm definitely the wrong person to ask because my solution was to write Rust. I think the machines C was conceived for are small enough by today's standards that I would not bring a high level language (like C) to the fight, a macro assembler and you'll be fine. For today's much larger machines, use Rust. Oh you've got 16-bit addressing? Chart all the addresses and what you'll use them for on a white board or a big sheet of paper. You do not need "allocators" like malloc, that's Steve's job, Steve has a sharpie to "allocate" memory on the chart.
  - inigyou 1mo ago
    Ironically I think to make the best use of such a small memory window, you'd want a compacting garbage collector. Lots of the 16-bit era BASICs used compacting GC for their strings. Yes you can statically allocate, but who wants an artificial limitation like "16 strings, 256 bytes each" when some users want 200 strings of 8 bytes and some users want 4 strings of 500 bytes. Static allocation is something you can do when your memory is large compared to your use cases.
designuki 1mo ago
> The "fix" in C11 is to just say we have the C++ 11 Memory Ordering Model and here are some built-ins for the ordered atomic operations that implies. Isn't Rust's solution mostly the same, just with C++20? https://doc.rust-lang.org/nomicon/atomics.html https://doc.rust-lang.org/nomicon/atomics.html > Rust pretty blatantly just inherits the memory model for atomics from C++20.
- tialaramex 1mo ago
  Rust does have the same Memory Ordering idea (minus the ill-fated "Consume" ordering) but provides richer tools for a modern world than C does. The C standard library provides nothing to actually do concurrency, such as making more threads, nor to synchronize them, such as with a mutex whereas of course Rust provides std::thread::spawn and std::sync::Mutex In C this is a platform specific problem, for Unix systems you want pthreads for example while Windows provides a different arrangement. Rust does not provide out-of-the-box structured concurrency - which I would like - but it's a lot closer to what I'd prefer here.
  - fanf2 1mo ago
    The C standard library has had <threads.h> since C11 https://www.cppreference.com/c/thread https://www.cppreference.com/c/thread and there are now a nonzero number of systems that support it! (glibc, musl, maybe others?)
    - tialaramex 1mo ago
      Well TIL. Thanks.