3 ms·

I'd be really interested in seeing this develop. Define a bytecode interpreter (JSVM?) and push bytecode into it. Performance may be god-awful, but you'd be fre

I'd be really interested in seeing this develop. Define a bytecode interpreter (JSVM?) and push bytecode into it. Performance may be god-awful, but you'd be free to use whatever language you fancy. Parchment is an example of the approach, implementing the z-machine VM in javascript. http://code.google.com/p/parchment/ http://code.google.com/p/parchment/

stcredzero 16y ago
Performance may be god-awful Why, after decades of JIT bytecode VMs, do we still have this misconception? Many of the widespread JVM implementations are faster than V8. LuaJIT and C# Mono are also VM implementations that JIT bytecode and are faster than V8! Is this a troll? http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u32/which-programming-lang...
- contextfree 16y ago
  I think he's suggesting a bytecode interpreter implemented in JavaScript.
- almost 16y ago
  The post you replied to seemed to be suggesting a VM written in Javascript. I don't think it's particularly controversial to speculate that the performance of that would be pretty awful :)
- stevecooperorg 16y ago
  As people have commented, I'm suggesting writing a javascript function which takes pre-compiled bytecode; like so; function interpret(bytecode) { // stack machine implementation goes here } And called like so; var bytecode = load("http://my.domain.com/myscript.bytecode"); interpret(bytecode); I'm not suggesting that bytecode is inherently slow -- just that I could take a great stab at writing a slow bytecode interpreter in JavaScript. ;) So under this scheme, you could do a server-side compilation of any language -- let's imagine Pascal as an example -- and deliver it back to the client as bytecode. Now you've broken the browser dependence on Javascript. At the cost of a VM written in JavaScript.
  - stcredzero 16y ago
    I'm suggesting writing a javascript function which takes pre-compiled bytecode Sorry, I misunderstood. Now you've broken the browser dependence on Javascript. At the cost of a VM written in JavaScript. I keep looking at these two sentences again. On one hand I know what you mean. On the other hand, this doesn't make any sense because it contradicts itself. (Which is why I misunderstood the original comment, I think.)

stcredzero 16y ago

Performance may be god-awful Why, after decades of JIT bytecode VMs, do we still have this misconception? Many of the widespread JVM implementations are faster than V8. LuaJIT and C# Mono are also VM implementations that JIT bytecode and are faster than V8! Is this a troll? http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u32/which-programming-lang...

contextfree 16y ago
I think he's suggesting a bytecode interpreter implemented in JavaScript.
almost 16y ago
The post you replied to seemed to be suggesting a VM written in Javascript. I don't think it's particularly controversial to speculate that the performance of that would be pretty awful :)
stevecooperorg 16y ago
As people have commented, I'm suggesting writing a javascript function which takes pre-compiled bytecode; like so; function interpret(bytecode) { // stack machine implementation goes here } And called like so; var bytecode = load("http://my.domain.com/myscript.bytecode"); interpret(bytecode); I'm not suggesting that bytecode is inherently slow -- just that I could take a great stab at writing a slow bytecode interpreter in JavaScript. ;) So under this scheme, you could do a server-side compilation of any language -- let's imagine Pascal as an example -- and deliver it back to the client as bytecode. Now you've broken the browser dependence on Javascript. At the cost of a VM written in JavaScript.
- stcredzero 16y ago
  I'm suggesting writing a javascript function which takes pre-compiled bytecode Sorry, I misunderstood. Now you've broken the browser dependence on Javascript. At the cost of a VM written in JavaScript. I keep looking at these two sentences again. On one hand I know what you mean. On the other hand, this doesn't make any sense because it contradicts itself. (Which is why I misunderstood the original comment, I think.)