Stream: wasmtime

Topic: no_std

Till Schneidereit (Jul 14 2020 at 10:44):

@Alex Crichton question about wasm-tools/41: would no-std-compat help with this, by any chance?

Alex Crichton (Jul 14 2020 at 10:45):

it might but it depends on the goal

Alex Crichton (Jul 14 2020 at 10:45):

if we were to commit to no_std suport then something like that probably makes sense

Alex Crichton (Jul 14 2020 at 10:45):

but I still feel somewhat strongly that we should not at all commit to no_std because I don't understand why we should

Till Schneidereit (Jul 14 2020 at 10:54):

one reason would be that there's increasing interest in Wasm in embedded environments. I think I understand the issues well enough to see why just no_std support doesn't really solve much, but if we could support it without bending over backwards in the implementation code of affected crates themselves, then it might be tenable?

Till Schneidereit (Jul 14 2020 at 10:54):

my, potentially wrong, understanding of no-std-compat is that it would allow us to do just that, no?

Alex Crichton (Jul 14 2020 at 11:07):

yes I don't want to block anything arbitrarily, and I understand that embedded folks are interested in no_std, but I really really don't want to just blindly follow where everyone else wants us to go

Alex Crichton (Jul 14 2020 at 11:07):

I think we're on the same page, but no one has yet to present me (in my opinion at least) a compelling reason to support no_std

Alex Crichton (Jul 14 2020 at 11:08):

like no one has a target where wasm/wasmtime actually make sense on the target, and the target has a really good reason to not support std

Alex Crichton (Jul 14 2020 at 11:10):

it's also worth pointing out that no-std-compat is a giant wad of code we would need to very carefully audit, and AFAIK no one's done that

Alex Crichton (Jul 14 2020 at 11:10):

naturally we're not just gonna blindly use it because it sounds nice, and right off the bat the usage of spin is inappropriate for us

Till Schneidereit (Jul 14 2020 at 11:11):

Alex Crichton said:

like no one has a target where wasm/wasmtime actually make sense on the target, and the target has a really good reason to not support std

yeah, I agree that we should only support no_std if there really is a compelling argument for it. Not sure if Tomaka's use case for Redshirt qualifies, but at least they think it does, AIUI

While `wasmi`, the Wasm interpreter, is very slow, I'd like to switch to `wasmtime` at some point. I have a branch with `wasmtime` working, but I can't merge it before I add support for running on bare metal. (8/10)

- tomaka (@tomaka17)

Till Schneidereit (Jul 14 2020 at 11:12):

Alex Crichton said:

it's also worth pointing out that no-std-compat is a giant wad of code we would need to very carefully audit, and AFAIK no one's done that

good point!

Alex Crichton (Jul 14 2020 at 11:13):

Of course yeah I don't want to rule anything out, but I don't want us to get into the mindset of "oh if we #![no_std] everything we run everywhere!"

Alex Crichton (Jul 14 2020 at 11:13):

that's a fallacy which will lead us to writing a bunch of spaghetti code

Alex Crichton (Jul 14 2020 at 11:13):

like does tomakas platform actually support mmap? and writable pages? (etc)

Till Schneidereit (Jul 14 2020 at 11:14):

makes sense, yes

Alex Crichton (Jul 14 2020 at 11:14):

basically what I'm saying is that supporting every target under the sun requires more careful planning than "let's blindly #![no_std] everything and play whack-a-mole until everything compiles"

Alex Crichton (Jul 14 2020 at 11:15):

we shouldn't do it just for doing it, but of course actually supporting these targets is fine

Alex Crichton (Jul 14 2020 at 11:15):

AFAIK we just don't have a story to actually support any of these targets other than "we wish we could"

Alex Crichton (Jul 14 2020 at 11:15):

like if tomaka's platform only supports interpreters then that's probably a better thing to design first than slapping #![no_std] everywhere

Alex Crichton (Jul 14 2020 at 11:16):

I also want to push back really hard on that if you have a libc (or some OS equivalent) then your platform really should support std

Alex Crichton (Jul 14 2020 at 11:16):

and I'm more than happy to do any work upstream necessary to make that a reality

Alex Crichton (Jul 14 2020 at 11:16):

std is core + libc, and that's basically it

Alex Crichton (Jul 14 2020 at 11:16):

and if your platform really truly only has core then you're like a microcontroller with 8k of rame

Till Schneidereit (Jul 14 2020 at 11:31):

Alex Crichton said:

and if your platform really truly only has core then you're like a microcontroller with 8k of rame

heh, fair

Till Schneidereit (Jul 14 2020 at 11:33):

to be clear, we definitely shouldn't do the work of creating this support, or even the story for supporting more esoteric platforms. What I do think would be good is to have documentation of our position on this that people can read to understand what they'd need to do to upstream changes supporting their platform

Alex Crichton (Jul 14 2020 at 11:54):

for sure yeah, and if needed I'd be happy to write up at least my own personal point of view

Till Schneidereit (Jul 14 2020 at 12:56):

I think that'd be great! Perhaps as part of the book, with a direct link from the main README.md?

Last updated: Nov 22 2024 at 17:03 UTC