@notriddle why?
do you agree that assembly that does nothing is safe?
so is asm that just check equivalency, so is asm that adds to u8 to an u32 (as registers).
my point is that there's a line when ASM becomes unsafe. and if we could push that line forward it would be pretty awesome for safety (as all programs end with an unsafe code, the question is how far can we push it)
Safety has semantic constraints that aren't represented at the register level. Maybe that register you're adding to is a NonZeroU32, and the addition changed it to 0, which would be undefined behavior. Or maybe that register is a 32-bit reference (safe pointer) and you're adding an offset. etc. etc. I suspect if you constrained the asm block such that it could be "type" analyzed at this level, you'd have code that doesn't really need asm at all.
The safe way to expose assembly is through intrinsics that LLVM will understand directly, with suitable wrappers at the Rust level as safety requires.
10 Likes
I would really like to see one day rust's libstd removing libc as a dependency. @gnzlbg do you have any thoughts on that? 
libstd does use cfg(target_env) already to distinguish between environments, so if you want a target triple that does not use libc, just add a new target triple, and implement libstd for it. You can use syscalls there with inline asm.
If you remove libc, you need to use something else instead. That else is some "libc-like" code on top of syscalls (just like every libc implementation). Go does that, so it can be done, but it's a lot of implementation and maintenance work on tricky unsafe code, and Go did end up having some very subtle bugs due to that. So not using your system's libc does not make everything magically better either. Doing that has its pros and cons. I think that choice is good, so this should definitely be a choice that users have.
2 Likes
ha. that's interesting. do you think upstream rust would accept a new x86_64_unknown_linux_bare target?
and if so how would it work? opt in only? (i.e. never chosen by default but is opted in)
Note that a significant amount of work necessary for creating a libc-free std has been already done by steed developers. See this issue for more information:
2 Likes
Steed is not the same think at all. It's a libstd implementation on top of syscalls. This is about wrapping syscalls, which can be used for handling features that libstd doesn't support. If someone also built a stdlib on top of that, that would be awesome. In addition we have the problem that since the introduction of procmacros the musl target is broken, so there is no way to create static binaries anymore. So there are a lot of reasons for this.
Are any of the linux experts here @gnzlbg @zackw open to receiving funding for delivering this?
A perspective Microsoft agrees with enough that Visual C++ doesn't support inline assembly for x64 and ARM targets.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.