Well, it's just a proof that _javascript_ is extremely well designed and powerful as it allows supporting any existing language, and even virtualization (it can also virtualize itself) independantly of how the native machine was actually built. This means that we'll see now machines specially optimized to support _javascript_ almost natively insteald of being built natively to give natural support to C. This could also change the paradigm about how processors are specially configured in their firmware: it could be as well reconfigured instantly or dynamically to support multiple instruction sets.
I’m not sure I (or many others) would agree that “_javascript_ is extremely well designed and powerful” [1]. And in general attempts to add language-specific optimizations to CPU instruction sets have rarely fared well (e.g. Java native bytecode on ARM). The whole point (to my mind) of RISC was to move to a model where a very streamlined CPU + low-latency L1 cache was, in effect, an engine for efficient execution of VMs like Lua’s.
In fact we were able to realize this very thing in our last project with Lua, in which pretty much the whole of the Lua VM, libraries, CPU stack and current set of Lua registers (stack frame) were all held in L1 cache on the CPU. In effect, the CPU at that point *IS* micro-coded for the Lua VM, and we saw spectacular performance from the VM as a result.
—Tim
|
