3 ms·

> duct-taped to a bundle of silly hacks, wrapped up in some interesting attempts to standardise, with a few more vendor-specific hacks crowbarred in there for g

> duct-taped to a bundle of silly hacks, wrapped up in some interesting attempts to standardise, with a few more vendor-specific hacks crowbarred in there for good measure By this point you could easily have been confused for someone describing amd64 (nee ia32, nee Pentium, i486, i386, 80286, 8088, 8080, 4004.. circa 1971). Just as we still have a perplexing set of registers and operations that happen to encode efficiently on this ubiquitous architecture due to their suitability to application in our distant ancestors' desktop calculators (binary-coded decimal, anyone?), no matter what kind of cleanliness you're alluding to existing in proposed alternatives that you might hope supplant Javascript.. in 40 years it'll look just as stale and nasty as x86 and Javascript do today. Not least PNaCl, where last I checked they were busy trying to shoehorn an architecture-specific binary format (bitcode) into something that might run on multiple machines. If that's not enough for you, the original NaCl relied on a vestigial 80286-specific hack (segmentation) that was finally removed in amd64. It's turtles all the way down.

PaperclipTaken 13y ago
Often times, there is enough reason to start over. With computer architectures, this has the risk of making every single existing operating system obsolete on your architecture. If you are planning on hitting a sales volume equivalent to amd64 sales, you can't just start over. Javascript is a different beast. By building Dart into your webrowser, you don't break the web browser. And while starting over will be an uphill battle, you can address much of the sillyness that holds javascript back and complicates it. Perhaps we have hit the limit of practical additions to javascript. The post yesterday showed that asm.js isn't actually faster unless your browser actually supports the optimizations, which makes popularizing optimized asm.js almost as difficult as popularizing Dart. I don't want to be using technology in 40 years that is built upon technology from 40 years ago. At some point we should reset, even the difficult technologies like amd64. How often is not a question I'm qualified to answer but it should happen.
deleted 13y ago
[deleted]
winter_blue 13y ago
> By this point you could easily have been confused for someone describing amd64 (nee ia32, nee Pentium, i486, i386, 80286, 8088, 8080, 4004.. circa 1971). He said "We need a real bytecode for the web" not some architecture-specific machine language like x86 et al. LLVM or JVM are examples of bytecode. They're highly portable (at least the JVM is), and they're not the mess that practically any real hardware instruction set is. > last I checked they were busy trying to shoehorn an architecture-specific binary format (bitcode) into something that might run on multiple machines The bitcode you're referring to is LLVM. It's an architecture-independent assembly that can be used to target most major real ISAs. For instance, the Clang compilers use LLVM as their backend. Any programming language designer could use LLVM and instantly (and easily) be able to generate native code for who knows how many different architectures. So I think the parent poster was right in what he/she said.
- hosay123 13y ago
  > He said "We need a real bytecode for the web That's what I was talking about, too. Since processors have essentially plateaued in performance improvements by increasing raw clock speed, the only growth options going forward are wider designs – increasingly unorthodox features (e.g. hardware-assisted TM) for which there is no historical precedent. I'm further hinting that no matter what utterly ideal format we pick, not 40 years from now.. perhaps not 10, perhaps not even 36 months time, some market participant will drop an architectural feature that completely obliterates contemporary thinking about what such an ideal format should look like. And once again we're back to x86-level cleanliness. So why take the penalty of a brand new mostly incompatible design when non-delusional incremental improvements would have got us there anyway.. > The bitcode you're referring to is LLVM. It's an architecture-independent assembly that can be used to target most major real ISAs http://thread.gmane.org/gmane.comp.compilers.llvm.devel/43769 http://thread.gmane.org/gmane.comp.compilers.llvm.devel/4376...
- michaelwww 13y ago
  Lars Bak and Kasper Lund (Hotspot, V8, Dart VM) discus the problems with a bytecode VM here starting at about 30:45 http://javascriptjabber.com/008-jsj-v8-and-dart-with-lars-bak-and-kaspar-lund/ http://javascriptjabber.com/008-jsj-v8-and-dart-with-lars-ba...

PaperclipTaken 13y ago

Often times, there is enough reason to start over. With computer architectures, this has the risk of making every single existing operating system obsolete on your architecture. If you are planning on hitting a sales volume equivalent to amd64 sales, you can't just start over. Javascript is a different beast. By building Dart into your webrowser, you don't break the web browser. And while starting over will be an uphill battle, you can address much of the sillyness that holds javascript back and complicates it. Perhaps we have hit the limit of practical additions to javascript. The post yesterday showed that asm.js isn't actually faster unless your browser actually supports the optimizations, which makes popularizing optimized asm.js almost as difficult as popularizing Dart. I don't want to be using technology in 40 years that is built upon technology from 40 years ago. At some point we should reset, even the difficult technologies like amd64. How often is not a question I'm qualified to answer but it should happen.

deleted 13y ago

[deleted]

winter_blue 13y ago

> By this point you could easily have been confused for someone describing amd64 (nee ia32, nee Pentium, i486, i386, 80286, 8088, 8080, 4004.. circa 1971). He said "We need a real bytecode for the web" not some architecture-specific machine language like x86 et al. LLVM or JVM are examples of bytecode. They're highly portable (at least the JVM is), and they're not the mess that practically any real hardware instruction set is. > last I checked they were busy trying to shoehorn an architecture-specific binary format (bitcode) into something that might run on multiple machines The bitcode you're referring to is LLVM. It's an architecture-independent assembly that can be used to target most major real ISAs. For instance, the Clang compilers use LLVM as their backend. Any programming language designer could use LLVM and instantly (and easily) be able to generate native code for who knows how many different architectures. So I think the parent poster was right in what he/she said.

hosay123 13y ago
> He said "We need a real bytecode for the web That's what I was talking about, too. Since processors have essentially plateaued in performance improvements by increasing raw clock speed, the only growth options going forward are wider designs – increasingly unorthodox features (e.g. hardware-assisted TM) for which there is no historical precedent. I'm further hinting that no matter what utterly ideal format we pick, not 40 years from now.. perhaps not 10, perhaps not even 36 months time, some market participant will drop an architectural feature that completely obliterates contemporary thinking about what such an ideal format should look like. And once again we're back to x86-level cleanliness. So why take the penalty of a brand new mostly incompatible design when non-delusional incremental improvements would have got us there anyway.. > The bitcode you're referring to is LLVM. It's an architecture-independent assembly that can be used to target most major real ISAs http://thread.gmane.org/gmane.comp.compilers.llvm.devel/43769 http://thread.gmane.org/gmane.comp.compilers.llvm.devel/4376...
michaelwww 13y ago
Lars Bak and Kasper Lund (Hotspot, V8, Dart VM) discus the problems with a bytecode VM here starting at about 30:45 http://javascriptjabber.com/008-jsj-v8-and-dart-with-lars-bak-and-kaspar-lund/ http://javascriptjabber.com/008-jsj-v8-and-dart-with-lars-ba...