> The main problem is that we just don't know how to create a perfect "one bytecode to rule them all"
It boggles me that the prevalence of the assumption that there should be a single bytecode. Not all tasks are the same. In real world computing an ATMega is sometimes a better choice than an ARM or an x86.
When Notch released the DCPU16 specification there were multiple compatible emulators running within 24 hours. After 3 days there were compilers. Supporting a bytecode can be easy. Optimizing for speed makes for a much more difficult task, but not all architectures must target the same goals.
The article lists the goals of Fast, Portable, and Safe. I would add to that list more goals. Deterministic and Efficient are two that spring to mind. I would advocate multiple bytecodes that favour some goals over others. The 8 bit AVR of the Arduino would be a good pick for a bytecode that has a light footprint that would be ideal for small tasks.
I wouldn't want a free-for-all with a massive proliferation of architectures, but at least three would mean there is a much better chance of having the right tool for the right job.
An ATMega is sometimes a better choice because it's cheaper and uses less power, not because it has a better instruction format. An 8-bit bytecode would be ideal for very little on a 64-bit computer (you'd end up simulating larger integer arithmetic that the machine can do in a single instruction, for no benefit); more generally, since the details of the target machine are going to vary anyway, there is no point in having multiple bytecodes with the same underlying memory and execution model that can be easily complied between.
Having a C-like bytecode and a Java-like bytecode and a Haskell-like bytecode would be more reasonable, but it would also be a huge pain for browser makers. One highly optimized VM is complex enough...
Having written assembly for x86, Arm, 8 bit AVR and indeed DCPU16, I disagree. Each performs particular functions better. More importantly, We should be able to disagree. You don't have to use my AVR-like bytecode and I don't have to use your Java-like bytecode.
Having a single "this works for me so it should work for everyone" is dumb. Like only supporting png as your only image format.
It boggles me that the prevalence of the assumption that there should be a single bytecode. Not all tasks are the same. In real world computing an ATMega is sometimes a better choice than an ARM or an x86.
When Notch released the DCPU16 specification there were multiple compatible emulators running within 24 hours. After 3 days there were compilers. Supporting a bytecode can be easy. Optimizing for speed makes for a much more difficult task, but not all architectures must target the same goals.
The article lists the goals of Fast, Portable, and Safe. I would add to that list more goals. Deterministic and Efficient are two that spring to mind. I would advocate multiple bytecodes that favour some goals over others. The 8 bit AVR of the Arduino would be a good pick for a bytecode that has a light footprint that would be ideal for small tasks.
I wouldn't want a free-for-all with a massive proliferation of architectures, but at least three would mean there is a much better chance of having the right tool for the right job.