4 ms·

I want to have fine-grained and full control over memory management. Can rust generate usefull machine code without a runtime and having to break one leg like

I want to have fine-grained and full control over memory management. Can rust generate usefull machine code without a runtime and having to break one leg like C?

MaulingMonkey 2y ago
> I want to have fine-grained and full control over memory management. Rust's global allocator is easy enough to replace on stable: https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html Per standard container allocators ala C++'s std::allocator haven't been stabilized, but are available on nightly: https://doc.rust-lang.org/std/alloc/trait.Allocator.html https://doc.rust-lang.org/std/alloc/trait.Allocator.html Alternatively, you can roll your own allocator ecosystem easily enough - my limited foray into this is mostly focused on interop with specific 3rd party allocator APIs from C, C++, Win32, etc.: https://docs.rs/ialloc/ https://docs.rs/ialloc/ , there are plenty of crates focusing on arena allocation etc. instead. > Can rust generate usefull machine code without a runtime and having to break one leg like C? Yes. At one extreme, you can create #![no_std] crates ( https://docs.rust-embedded.org/book/intro/no-std.html https://docs.rust-embedded.org/book/intro/no-std.html ) which don't assume you can create threads, write to stdio, or even allocate heap memory. I've gotten Rust static libraries linking into "unsupported" platforms in minutes (when it had an LLVM-compatible linker available.) At the other extreme, I've previously ported Rust's standard library to an unsupported NDAed platform. It's easy to stub out unsupported bits - the code for such stubs already exists to support wasm32-unknown-unknown (arguably a mistake, but it's a useful one!) - and replacing those stubs with real code isn't too onerous in my experience either. Middle grounds of `extern crate alloc;` let you support subsets of "the standard library" as well. Yanking all "runtime" support out of existing platforms might be a bit trickier (e.g. there's a little code to support populating std::env on *nix, a little mucking with default signal handling, and e.g. windows builds will use Win32 APIs for backtracing and unwinding for panics - ripping that all out is more obnoxious, but also pointless IMO.) Some non-NDAed examples of targeting funky stuff: • https://github.com/MaulingMonkey/uefi-hello-world https://github.com/MaulingMonkey/uefi-hello-world (why write hello world for windows when you can directly boot hello world?) • https://github.com/MaulingMonkey/rust-opendingux-test https://github.com/MaulingMonkey/rust-opendingux-test (old, linuxy - see Notes.md, consider using -Zbuild-std instead of Xargo these days?)
diggan 2y ago
> Can rust generate usefull machine code without a runtime Afaik, the only runtime parts of Rust are panic handling, standard library and thread management. You can disable the standard library with `#![no_std]`, and I'm fairly sure you can also disable the panic handling (but not 100%) and I don't know if you can disable thread management at all. But if you can, I think you can have what you're asking for :) Edit: In fact, the `no_std` might actually disable all of the above, not just the stdlib.
- kibwen 2y ago
  > thread management Note that the "runtime parts" in question here refers to initializing OS-level threads, the same as in C. It's not referring to any sort of userspace green thread runtime (which you would need to bring in yourself). no_std disables the parts of the standard lib that rely on having an OS (e.g. threads) or having an allocator. (You can get the allocator parts back in a no_std program if you define your own allocator.) "Panics" aren't something you'd disable, a panic is just a mechanism for crashing the program in a controlled manner. Rust lets you decide whether or not you want panics to abort the program immediately or whether to unwind the program and run destructors, and you can configure this in any Rust codebase via a config key/compiler flag. (If you're using no_std then you can technically also define panics as being an infinite loop, rather than crashing.)
  - wavemode 2y ago
    Rust does feature panic recovery as well: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html
    - leftyspook 2y ago
      That essentially comes for free with stack unwind, and will not be possible with `panic=abort`
kibwen 2y ago
I would call Rust comparable to C when it comes to giving you the ability to have control over memory management and machine code. Which is to say, if you have a problem with how C does it, then I doubt that Rust will make you any happier in this regard. What pain points in C is this referring to specifically?
sapiogram 2y ago
I think you need to specify what you mean by "without a runtime". Do you mean "without a garbage collector"? "Without memory allocation"? Even C has a runtime, just a very small one.
- sylware 2y ago
  I am talking C without any runtime: machine code or data are _ONLY_ from the C code (and OS interaction is done with raw syscalls). Can I do the same in rust?
  - leftyspook 2y ago
    Yes.
    - sylware 2y ago
      Getting mixed signals about this. Lies are flying all over. I'll need to check that by myself one day. What's seems to be really sure though is the filth of rust syntax complexity on par with the other filthy one, c++.
steveklabnik 2y ago
The smallest binary rustc has ever spit out is like 137 bytes. It has the exact same amount of runtime requirements as C. The default configurations aren’t optimizing for size, but if you want to strip it down, you can.
pjmlp 2y ago
You will always have Assembly for driving dangerously fast without either a seatbelt, nor an helmet. By the way, even C has a runtime, without which several ISO C features aren't available. That is why there is a freestanding section.
- sylware 2y ago
  So it means rust cannot do that. Ok, next.
  - pjmlp 2y ago
    It definitely can, I decided not answer that. For example, Microsoft has thrown away all their C code on Pluton CPU firmware and replaced it with Rust. Likewise Google has been shipping Rust on Linux kernel downstream fork on Android for several versions now, regardless of upstream drama. And any recent Windows 11 version runs Rust kernel code, every single time anything on the screen, after the GDI regions handling C kernel code has been rewriten in Rust. The cargo cult that C is the be all, end all of systems programming gets tiresome after a few decades.
    - sylware 2y ago
      If you think google and microsoft are good examples, good on you :). That said... I have been having seriously mixed signals about this. In the end, I'll have to check that by myself to get a final answer to who is lying here. And there is already an issue with rust: its toolchain cannot statically link libgcc (bug since 2015?!). And it seems rust syntax has the same toxic complexity than the filthy c++ one which would make it a definitive nono for many.
      - pjmlp 2y ago
        They definitely are, more than most of us on HN ever dream to achive leaving our mark on the industry.
        2y ago

I want to have fine-grained and full control over memory management. Can rust generate usefull machine code without a runtime and having to break one leg like C?

MaulingMonkey 2y ago

> I want to have fine-grained and full control over memory management. Rust's global allocator is easy enough to replace on stable: https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html Per standard container allocators ala C++'s std::allocator haven't been stabilized, but are available on nightly: https://doc.rust-lang.org/std/alloc/trait.Allocator.html https://doc.rust-lang.org/std/alloc/trait.Allocator.html Alternatively, you can roll your own allocator ecosystem easily enough - my limited foray into this is mostly focused on interop with specific 3rd party allocator APIs from C, C++, Win32, etc.: https://docs.rs/ialloc/ https://docs.rs/ialloc/ , there are plenty of crates focusing on arena allocation etc. instead. > Can rust generate usefull machine code without a runtime and having to break one leg like C? Yes. At one extreme, you can create #![no_std] crates ( https://docs.rust-embedded.org/book/intro/no-std.html https://docs.rust-embedded.org/book/intro/no-std.html ) which don't assume you can create threads, write to stdio, or even allocate heap memory. I've gotten Rust static libraries linking into "unsupported" platforms in minutes (when it had an LLVM-compatible linker available.) At the other extreme, I've previously ported Rust's standard library to an unsupported NDAed platform. It's easy to stub out unsupported bits - the code for such stubs already exists to support wasm32-unknown-unknown (arguably a mistake, but it's a useful one!) - and replacing those stubs with real code isn't too onerous in my experience either. Middle grounds of `extern crate alloc;` let you support subsets of "the standard library" as well. Yanking all "runtime" support out of existing platforms might be a bit trickier (e.g. there's a little code to support populating std::env on *nix, a little mucking with default signal handling, and e.g. windows builds will use Win32 APIs for backtracing and unwinding for panics - ripping that all out is more obnoxious, but also pointless IMO.) Some non-NDAed examples of targeting funky stuff: • https://github.com/MaulingMonkey/uefi-hello-world https://github.com/MaulingMonkey/uefi-hello-world (why write hello world for windows when you can directly boot hello world?) • https://github.com/MaulingMonkey/rust-opendingux-test https://github.com/MaulingMonkey/rust-opendingux-test (old, linuxy - see Notes.md, consider using -Zbuild-std instead of Xargo these days?)

diggan 2y ago

> Can rust generate usefull machine code without a runtime Afaik, the only runtime parts of Rust are panic handling, standard library and thread management. You can disable the standard library with `#![no_std]`, and I'm fairly sure you can also disable the panic handling (but not 100%) and I don't know if you can disable thread management at all. But if you can, I think you can have what you're asking for :) Edit: In fact, the `no_std` might actually disable all of the above, not just the stdlib.

kibwen 2y ago
> thread management Note that the "runtime parts" in question here refers to initializing OS-level threads, the same as in C. It's not referring to any sort of userspace green thread runtime (which you would need to bring in yourself). no_std disables the parts of the standard lib that rely on having an OS (e.g. threads) or having an allocator. (You can get the allocator parts back in a no_std program if you define your own allocator.) "Panics" aren't something you'd disable, a panic is just a mechanism for crashing the program in a controlled manner. Rust lets you decide whether or not you want panics to abort the program immediately or whether to unwind the program and run destructors, and you can configure this in any Rust codebase via a config key/compiler flag. (If you're using no_std then you can technically also define panics as being an infinite loop, rather than crashing.)
- wavemode 2y ago
  Rust does feature panic recovery as well: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html
  - leftyspook 2y ago
    That essentially comes for free with stack unwind, and will not be possible with `panic=abort`

kibwen 2y ago

I would call Rust comparable to C when it comes to giving you the ability to have control over memory management and machine code. Which is to say, if you have a problem with how C does it, then I doubt that Rust will make you any happier in this regard. What pain points in C is this referring to specifically?

sapiogram 2y ago

I think you need to specify what you mean by "without a runtime". Do you mean "without a garbage collector"? "Without memory allocation"? Even C has a runtime, just a very small one.

sylware 2y ago
I am talking C without any runtime: machine code or data are _ONLY_ from the C code (and OS interaction is done with raw syscalls). Can I do the same in rust?
- leftyspook 2y ago
  Yes.
  - sylware 2y ago
    Getting mixed signals about this. Lies are flying all over. I'll need to check that by myself one day. What's seems to be really sure though is the filth of rust syntax complexity on par with the other filthy one, c++.

steveklabnik 2y ago

The smallest binary rustc has ever spit out is like 137 bytes. It has the exact same amount of runtime requirements as C. The default configurations aren’t optimizing for size, but if you want to strip it down, you can.

pjmlp 2y ago

You will always have Assembly for driving dangerously fast without either a seatbelt, nor an helmet. By the way, even C has a runtime, without which several ISO C features aren't available. That is why there is a freestanding section.

sylware 2y ago
So it means rust cannot do that. Ok, next.
- pjmlp 2y ago
  It definitely can, I decided not answer that. For example, Microsoft has thrown away all their C code on Pluton CPU firmware and replaced it with Rust. Likewise Google has been shipping Rust on Linux kernel downstream fork on Android for several versions now, regardless of upstream drama. And any recent Windows 11 version runs Rust kernel code, every single time anything on the screen, after the GDI regions handling C kernel code has been rewriten in Rust. The cargo cult that C is the be all, end all of systems programming gets tiresome after a few decades.
  - sylware 2y ago
    If you think google and microsoft are good examples, good on you :). That said... I have been having seriously mixed signals about this. In the end, I'll have to check that by myself to get a final answer to who is lying here. And there is already an issue with rust: its toolchain cannot statically link libgcc (bug since 2015?!). And it seems rust syntax has the same toxic complexity than the filthy c++ one which would make it a definitive nono for many.
    - pjmlp 2y ago
      They definitely are, more than most of us on HN ever dream to achive leaving our mark on the industry.
      - 2y ago