Sounds like this is intended to run on targets rustc would not support, given the claim that it "does not assume 8-bit addressability".
Also, while I'm fully on board the "Rust as a default userspace systems language," the machine code I've gotten out of trying #[no_std] Rust to write part of a bare-metal project was heinously bloated. This is without even using any non-libcore dependencies! Something like 3/4s of the machine instructions looked like they were related to building error messages for panics, despite the fact that there shouldn't have been any reachable panics (and the code was small and simple enough that I expected LLVM to be able to reason about this without any MIR-level optimizations).
Maybe this would be better on a project that could use rustc as its linker, but based on this, I wouldn't necessarily recommend that a bare-metal library intended to be linked to C and hand-written assembly be written in Rust versus, say, verified with Frama-C or other C-specific tools.
To be fair, the AVR and STM8 code I’ve got out of GCC and SDCC when feeding them normal (non-8-bitter-adapted) C also sucked—though not to the point of building strings—because the default promotion to int required by the standard really hurts when the minimum required 16-bit int does not fit into a register.
I'm latching onto a non-main argument to be pedantic, but I'd like to mention that Rust is fine for _non-embedded_ kernel development too, in my experience.
As you're likely aware, Rust for embedded sucks when there's no HAL, but should be pretty pleasant otherwise. Have you looked into the cortex-a[1] crate?
Some unnecessary instructions could also be a part of an ongoing optimization effort[2][3].
Also, while I'm fully on board the "Rust as a default userspace systems language," the machine code I've gotten out of trying #[no_std] Rust to write part of a bare-metal project was heinously bloated. This is without even using any non-libcore dependencies! Something like 3/4s of the machine instructions looked like they were related to building error messages for panics, despite the fact that there shouldn't have been any reachable panics (and the code was small and simple enough that I expected LLVM to be able to reason about this without any MIR-level optimizations).
Maybe this would be better on a project that could use rustc as its linker, but based on this, I wouldn't necessarily recommend that a bare-metal library intended to be linked to C and hand-written assembly be written in Rust versus, say, verified with Frama-C or other C-specific tools.