Skip to content
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

Open
dumblob opened this issue Apr 23, 2021 · 8 comments
Open

Any future? #6

dumblob opened this issue Apr 23, 2021 · 8 comments

Comments

@dumblob
Copy link

dumblob commented Apr 23, 2021

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.

@pmp-p
Copy link

pmp-p commented Apr 23, 2021

WASM ecosystem seems well prepared for such use cases.

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." )

@dumblob
Copy link
Author

dumblob commented Apr 23, 2021

WASM ecosystem seems well prepared for such use cases.

i really wonder what makes you think that, because for iot wasm consumes way too much RAM for rodata.

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.

Sorry to intrude but i think it could help interested people to know there is discussion about those cases here https://discord.gg/qVN9rEtgjr ( WasmAssembly/Embedded )

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).

@piranna
Copy link
Owner

piranna commented Apr 27, 2021

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 :-)

@dumblob
Copy link
Author

dumblob commented Apr 27, 2021

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.

@piranna
Copy link
Owner

piranna commented Apr 27, 2021

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 .

What findings, exactly?

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.

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 :-(

@dumblob
Copy link
Author

dumblob commented Apr 27, 2021

What findings, exactly?

E.g. everything discussed in WebAssembly/design#1050 .

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?

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).

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 :-(

Take it easy - life has strict precedence! No qualms!

@vshymanskyy
Copy link

vshymanskyy commented May 10, 2021

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

As co-author of Wasm3, I was also thinking about this.

  • Generally speaking, wasm could be used as an ISA, but as such it would be a CISC machine. In this sense, it could be more efficient to translate it dynamically into some internal microcode, similarly to what Intel CPUs do. Which is a very complicated architecture.
  • This also raises a question like "would this machine be actually more performant"? And the answer is likely either "no" or "barely".
  • Wasm3 does translate wasm bytecode into internal "fast" representation (so, we got to the same concept of microcode). It's very different from CPU microcode, because it's optimized for being executed by a (rather simple) VM.

@piranna
Copy link
Owner

piranna commented May 11, 2021

@dumblob

E.g. everything discussed in WebAssembly/design#1050 .

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 :-)

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).

Interesting. Maybe we could do something with this, then? Probably I can help with comments and advice if someone want to take the initiative.

Take it easy - life has strict precedence! No qualms!

I supose... thank you for your words :-)

@vshymanskyy

As co-author of Wasm3, I was also thinking about this.

Oh, thank you for writting here, I feel honored, you've done a good work with Wasm3 :-)

  • Generally speaking, wasm could be used as an ISA, but as such it would be a CISC machine.

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 :-)

  • In this sense, it could be more efficient to translate it dynamically into some internal microcode, similarly to what Intel CPUs do.

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.

  • This also raises a question like "would this machine be actually more performant"? And the answer is likely either "no" or "barely".

Are you talking about WasMachine vs WebAssembly transpiled to general CPU, or about CISC version of WasMachine vs what exactly?

  • Wasm3 does translate wasm bytecode into internal "fast" representation (so, we got to the same concept of microcode). It's very different from CPU microcode, because it's optimized for being executed by a (rather simple) VM.

Then it seems like the concept is very similar to my idea of WASD - WebAssembly Decoded binary format, isn't it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants