3 ms·

API are OK but they are tedious to implement. You have to discover the good way to manage each subsystem. I think of something more low level for a VM that cou

API are OK but they are tedious to implement. You have to discover the good way to manage each subsystem. I think of something more low level for a VM that could run inside a web worker (or in the main thread). It's visible interface could be (with ArrayBuffer): - an address space for a virtual framebuffer - an address space for a virtual disk - i/o with ports for sockets, mouse, keyboard ... With that, we could use existing OS. There is too much case to implement all the existing API and each case can be complicated and have implicit assumptions. For example, instead of mapping fopen() paths to localStorage or URLs in XHR, we could implement an existing hadware API for disk storage. Instead of implementing SDL, implement a VGA memory. I think it is more reliable to use on the lowest interface and you can reuse all the stack (from the kernel, to GNOME and Firefox, all inside the browser). The rules of mapping what to what will be defined outside the VM. The browser could be in charge of these rules. The rules are: - save this address space to localStorage (or IndexDB) - send this address space in XHR (or websocket) - put this address space to this canvas (with putImageData()) I had this idea after reading a spec of a VM for a Forth: http://retroforth.org/docs/The_Ngaro_Virtual_Machine.html#i-o-ports http://retroforth.org/docs/The_Ngaro_Virtual_Machine.html#i-... I'm not criticizing your work nor emscripten at all. I'm a big fan :-) It's more about making the things simpler, get rid of the complexity, increase the features and liberate everybody of the burden of mapping native API to Web API. It's like Cygwin vs qemu/kvm. I'd like to help emscripten and I see that.

azakai 11y ago
Making a new set of APIs like that would need to be done very carefully, to keep the web consistent and also to make sure it is sandboxed properly and so forth. In general the web is actually going in that direction, for example WebGL is similar to low-level OpenGL. But obviously in many other APIs, that is not the case. There are proposals for various new APIs, like for file storage, but they are each being debated separately. I don't think WebAssembly is going to change anything in that regard - we can propose new APIs for it, but the proposals will go through the usual processes.
- vmorgulis 11y ago
  The solution is somewhere in the qemu or kvm world but qemu deals with real hardware. I'm looking for something simpler than a real machine. Ideally, qemu could run a virtual cpu just made for asm.js or wasm. The virtual hardware is accessed thru the Module functions. We could have a peek() and a poke() like in the old days to read the ports :-) I remember your first posts about emscripten and the first script in Python. The gap to fill is similar to "write a backend for LLVM" as you did (not enough, of course). There is also the x86 emulator from copy.sh (http://copy.sh/v86/ http://copy.sh/v86/). The general direction is "support blobs in the browser". About implementing new Web API, I think the process is not so slow but it relies on non-technical things (like strategy for the companies) so low level would speed up that.

azakai 11y ago

Making a new set of APIs like that would need to be done very carefully, to keep the web consistent and also to make sure it is sandboxed properly and so forth. In general the web is actually going in that direction, for example WebGL is similar to low-level OpenGL. But obviously in many other APIs, that is not the case. There are proposals for various new APIs, like for file storage, but they are each being debated separately. I don't think WebAssembly is going to change anything in that regard - we can propose new APIs for it, but the proposals will go through the usual processes.

vmorgulis 11y ago
The solution is somewhere in the qemu or kvm world but qemu deals with real hardware. I'm looking for something simpler than a real machine. Ideally, qemu could run a virtual cpu just made for asm.js or wasm. The virtual hardware is accessed thru the Module functions. We could have a peek() and a poke() like in the old days to read the ports :-) I remember your first posts about emscripten and the first script in Python. The gap to fill is similar to "write a backend for LLVM" as you did (not enough, of course). There is also the x86 emulator from copy.sh (http://copy.sh/v86/ http://copy.sh/v86/). The general direction is "support blobs in the browser". About implementing new Web API, I think the process is not so slow but it relies on non-technical things (like strategy for the companies) so low level would speed up that.