3 ms·

> 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

> 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...
azakai 13y ago
> The bitcode you're referring to is LLVM. It's an architecture-independent assembly It is abstracted over specific CPU instructions, but is not portable and not intended to be. It can contain CPU and OS-specific patterns. It is possible to convert LLVM bytecode into something portable though, or at least a subset of it. That is sort of what Emscripten and PNaCl do.

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...

azakai 13y ago

> The bitcode you're referring to is LLVM. It's an architecture-independent assembly It is abstracted over specific CPU instructions, but is not portable and not intended to be. It can contain CPU and OS-specific patterns. It is possible to convert LLVM bytecode into something portable though, or at least a subset of it. That is sort of what Emscripten and PNaCl do.