-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Any future? #6
Comments
i really wonder what makes you think that, because for iot wasm consumes way too much RAM for rodata. Sorry to intrude but i think it could help interested people to know there is discussion about those cases here https://discord.gg/qVN9rEtgjr ( WebAssembly/Embedded with topic "Embedded, IoT, bare metal." ) |
Well, if ~10 Kbytes of RAM are too much, then sure, WASM is not perfect fit for that. But my feeling is, that most FPGA systems offer more 😉. That's why I'm asking about any future plans.
Thanks for the pointer! If anybody wants to discuss IoT, please join that discussion and don't discuss it here (this issue is about future plans for wasmachine). |
Main problems to the future of the project are that I'm not at all an expert in hardware design (this was my first project), so the initial aproach was very naïve, and had no time to work on the full refactor. For this I was looking for some financiation, the same for my other Open Source projects, without luck. Also, I don't know how much performant would it be compared to desktop CPUs. For embeded systems and IoT (I was told this would be useful for SmartCards), not sure how much performant would this be compared to have a small RISC-V CPU and compile WebAssembly to it beforehand. Lastly, the major pushdown has been that WebAssembly binary format is optimized for space, and it's not possible (or very difficult and low performant) to execute it directly in place as how initialy though. I was thinking to have my own binary encoding optimized for execution in place (fixed number format instead of varlength, length of block on conditionals to jump...) but that would be like designing a new ISA and, although it could be done in anoother VHDL loader module, it would need to be compiled before hand anyway. I'm open for help and discussions, though :-) |
Thanks for shedding some light on the broader situation. It doesn't sound like something to pursue at all costs in the form as it stands. So far though I find the findings you made very important for future development of anything targetting WASM. So your time didn't end up in vain 😉. Regarding usefulness I'm still convinced there is some non-niche market behind this. It's just that the time has apparently not yet come. Feel free to close this if you find fit. I'll leave it open if anyone wanted to chime in. |
What findings, exactly?
I was told about the SmartCards, but being able to run wasm3 in a ESP32, what advantage would provide to have a custom-tailored CPU for an unique binary WebAssembly encoding vs wasm3 or compile directly to ESP32? Use case, bussiness model... I used to do the things just for fun, but now I have too much work, and have lost a lot of time in front of a computer instead of enjoying life :-/ My other big project NodeOS has suffered from the same illness, and I fell culprit of that :-( |
E.g. everything discussed in WebAssembly/design#1050 .
I think it could be e.g. a sweet spot between DSP (digital signal processing), ML (machine learning), and uC/CPU (turing complete computational processing unit) while being more or less comparably power efficient (sometimes more sometimes less).
Take it easy - life has strict precedence! No qualms! |
As co-author of Wasm3, I was also thinking about this.
|
I feel guilty by that, in fact... if I would started to participate once I learned about WebAssembly two years before, probably the bytecode would have been different and could have been able to be directly executed, but didn't know about VHDL then to do it. But yes, comments on that issue were interesting :-)
Interesting. Maybe we could do something with this, then? Probably I can help with comments and advice if someone want to take the initiative.
I supose... thank you for your words :-)
Oh, thank you for writting here, I feel honored, you've done a good work with Wasm3 :-)
Interesting, didn't thought about that... On university we only studied RISC CPUs design (MIPS and Zepto-CPU), and only read about CISC in old books. I know about Intel x86 CPUs translate on the fly to an internal RISC CPU, that would be a really cool design for WasMachine, didn't thought about that :-)
My original idea was to do a direct execution, but being so difficult in some parts due to the binary form, I was thinking about having a loader module as part of WasMachine CPU that get the WebAssembly bytestream and parse and process it, filling RAM with the decoded and easy to execute instructions. Doing it on the fly would make it transparent, but for info that needs to be scanned like jump destination on conditionals, would be a waste of clock cycles vs a custom bytestream with the destination next to the conditional opcode. Do you have some idea for this? Decode of varlength variables is a problem too, but it's mostly solved and just only it makes paths longer... that directly affect to the CPU frequency.
Are you talking about WasMachine vs WebAssembly transpiled to general CPU, or about CISC version of WasMachine vs what exactly?
Then it seems like the concept is very similar to my idea of WASD - WebAssembly Decoded binary format, isn't it? |
Any plans to continue this interesting work? This might be very interesting for IoT as small FPGAs are already quite cheap and WASM ecosystem seems well prepared for such use cases.
The text was updated successfully, but these errors were encountered: