Re:A look at asm.js and the future with WebAssembly
by Lerc on Saturday January 16, 2016 @06:55AM
(#10915058)
I have certainly given this a great deal of thought. What is needed? How could we get from here to there?
People have often called for a ByteCode vm. This has been rejected over and over again. Bendan Eich in particular has repeatedly argued against bytecode in ways I found to be quite disingenuous. He has variously used Java to imply one bytecode being unsuitable means all bytecodes are unsuitable, or suggested if you want bytecode to make a bytecode VM in JavaScript (even using DCPU16 as an example), or that it is too late for a new standard, or that. No bytecode would be accepted by all browser makers (which I took to mean 'not on my watch'). I have yet to find the arguments against a bytecode VM to be convincing.
I think it would be well worth making a few different candidate bytecode VMs to give the platform a chance in the field. Such VMs are not hard. In the case of the DCPU16 (A imaginary CPU created for a project Notch was working on) it took less than 48 hours for emulators to appear and just under a week for the first compiler. A VM that occupies a similar space to Javascript has its own particular needs.
The cooperative multitasking aspect of JavaScript has been a bugbear for all too long. I have argued for a preemption mechanism of some sort that would fix the dependency on a main loop event pump. I have half a specification written as a proposal, but I suspect people will fight the idea tooth-and-nail.
Ideally a solution should encompass concurrency as much as preemption. I kind of like the idea of A bytecode VM with an arbitrary number of virtual CPUS. A fork instruction to launch a new CPU. The VM host is free to run them on however many actual cpus as it sees fit.
People have often called for a ByteCode vm. This has been rejected over and over again. Bendan Eich in particular has repeatedly argued against bytecode in ways I found to be quite disingenuous. He has variously used Java to imply one bytecode being unsuitable means all bytecodes are unsuitable, or suggested if you want bytecode to make a bytecode VM in JavaScript (even using DCPU16 as an example), or that it is too late for a new standard, or that. No bytecode would be accepted by all browser makers (which I took to mean 'not on my watch'). I have yet to find the arguments against a bytecode VM to be convincing.
I think it would be well worth making a few different candidate bytecode VMs to give the platform a chance in the field. Such VMs are not hard. In the case of the DCPU16 (A imaginary CPU created for a project Notch was working on) it took less than 48 hours for emulators to appear and just under a week for the first compiler. A VM that occupies a similar space to Javascript has its own particular needs.
In a different direction Maxime Chevalier-Boisvert argues for a Control Flow Graph representation http://pointersgonewild.com/2015/08/02/javascript-is-the-c-o... Which if the Webassembly approach is to be taken this does seem more sensible than a AST.
The cooperative multitasking aspect of JavaScript has been a bugbear for all too long. I have argued for a preemption mechanism of some sort that would fix the dependency on a main loop event pump. I have half a specification written as a proposal, but I suspect people will fight the idea tooth-and-nail.
Ideally a solution should encompass concurrency as much as preemption. I kind of like the idea of A bytecode VM with an arbitrary number of virtual CPUS. A fork instruction to launch a new CPU. The VM host is free to run them on however many actual cpus as it sees fit.