3 ms·

I don't really like this article. Bytecode is an abstraction of machine code. No, it isn't an abstraction if a few paragraphs later the author gives SuspendGe

I don't really like this article. Bytecode is an abstraction of machine code. No, it isn't an abstraction if a few paragraphs later the author gives SuspendGenerator as an example bytecode. Abstraction is the wrong word here. A bytecode is a machine instruction for a virtual machine. In this case, the V8 bytecode is a higher level ISA than is for example, ARMv8; that would be more accurate. System 38 MI is a higher level ISA as well. Ignition, the interpreter, generates bytecode from this syntax tree. No, interpreters don't generate bytecode. They interpret bytecode; that's why they're called interpreters. Code generators generate code; that's why they're called code generators. However that said, this must be a strange description internal to the V8 group since it shows up here as well: https://v8project.blogspot.com/2016/08/firing-up-ignition-interpreter.html https://v8project.blogspot.com/2016/08/firing-up-ignition-in... You can generate code, bytecode, directly from an AST. You can do that. That is probably what is happening and what is meant here. On the other hand, LLVM converts an AST into an SSA IR and optimizes then lowers that. V8 is a JIT pipeline and LLVM is a traditional compiler pipeline.

infogulch 9y ago
It's possible that the code generator and interpreter are bundled. (Though I have no idea in this specific case.) For example, it could be that the parser always passes the AST result to the interpreter which generates and starts to interpret the resulting bytecode directly. Then later it's passed to the JIT from there.
pmelendez 9y ago
"They interpret bytecode; that's why they're called interpreters." This is not universally true. Back in the day, interpreters execute machine code directly from source code. I still remember the debates about whether the JVM should be consider an interpreter. It is a bit of a pointless debate in my opinion anyway.
dahart 9y ago
> No, interpreters don't generate bytecode. They interpret bytecode; that's why they're called interpreters. Code generators generate code; FWIW, personally I prefer the article's idea of interpreters over yours, and I speculate the article's is more representative of what most people think. I've never heard interpreters described the way you just did, as the part that interprets bytecode. (But I did find discussion of "bytecode interpreters" in the WP article, link below). Normally, an interpreter is a complete alternative to a compiler. Usually, an interpreter is more or less synonymous with a programming language "shell", or even the whole programming language. The Python shell would be an interpreter, for example. In my mind, virtual machines are what you call the thing that executes bytecode, not interpreters. I'd assume that someone talking about an "interpreter" without any other qualification was talking about a program that reads & runs a another program written in a scripting language. As time passes, these lines are getting blurrier. V8 is liberally mixing concepts from compilers and interpreters, so it's dangerous to draw hard lines. But you might be interested to double-check the broad strokes. https://en.m.wikipedia.org/wiki/Interpreter_(computing) https://en.m.wikipedia.org/wiki/Interpreter_(computing) > Abstraction is the wrong word here. The bytecode binary runs without modification on multiple hardware platforms. It's pretty reasonable to call that an abstraction of machine code. Because it is.
- CalChris 9y ago
  > Normally, an interpreter is a complete alternative to a compiler. Yes, that would be the Bill Gates MS Basic or Forth sense of interpreter. But it wouldn't be the post parsing, here's an AST, now what do we do with it sense. If they called V8 an interpreter (they call it an engine) I could see that although it would still seem archaic usage. But they're stitching Ignition on the side of V8 and calling that an interpreter which is just strange. > The bytecode binary runs without modification on multiple hardware platforms. It's pretty reasonable to call that an abstraction of machine code. No, that's portability onto multiple platforms. But the article said Bytecode is an abstraction of machine code. 'Abstraction of' vs 'runs on', these are two very different concepts.
  - dahart 9y ago
    > Yes, that would be the Bill Gates MS Basic or Forth sense of interpreter. But it wouldn't be the post parsing, here's an AST, now what do we do with it sense. It's also the JavaScript, Python, Haskell, Perl, Ruby, bash, etc. etc. etc. sense of the word interpreter. You can use it to describe all languages that aren't compiled. You said interpreters "interpret bytecode". You claimed that a bytecode interpreter was the broadest definition of interpreter, and that saying the interpreter is what reads source JavaScript and turns it into bytecode was wrong. I disagree, and Wikipedia does too. Many, perhaps even most interpreters don't even involve bytecode at all. You're entitled to your opinion, but I guess just expect some pushback if you're going to try to correct people using your narrow, uncommon idea of what makes an interpreter. > No, that's portability onto multiple platforms. Normally when I'm talking about code with other people, "portable" means code you can re-compile for a platform, not that the binary runs without modification. But, sure, I'd agree that it's reasonable to call bytecode a mechanism for portability. The way it does that is by abstracting away a specific platform's assembly language in favor of one that runs on multiple platforms. People call programming languages like C & Python an abstraction of machine language. JavaScript's bytecode is just that - it's a low level programming language. And as such, it's abstracting the hardware. Virtual machines are an attempt to abstract the CPU specifics and have code that runs anywhere. > 'Abstraction of' vs 'runs on', these are very different concepts. I don't know what your definition of abstraction is, but based on your objections, it feels like you have a narrow and rigid idea that perhaps doesn't match the common usage. A function that takes a parameter is an abstraction of a block of code, just like any programming language that runs on multiple platforms is an abstraction of a specific CPU or machine language.
oscargrouch 9y ago
> Ignition, the interpreter, generates bytecode from this syntax tree. I guess she was addressing something more V8 specific. In the case of V8, the Ignition 'module' first generates the bytecode directly from the AST, and then in another step, interpret the generated bytecode. So, in this particular case it does both.

infogulch 9y ago

It's possible that the code generator and interpreter are bundled. (Though I have no idea in this specific case.) For example, it could be that the parser always passes the AST result to the interpreter which generates and starts to interpret the resulting bytecode directly. Then later it's passed to the JIT from there.

pmelendez 9y ago

"They interpret bytecode; that's why they're called interpreters." This is not universally true. Back in the day, interpreters execute machine code directly from source code. I still remember the debates about whether the JVM should be consider an interpreter. It is a bit of a pointless debate in my opinion anyway.

dahart 9y ago

> No, interpreters don't generate bytecode. They interpret bytecode; that's why they're called interpreters. Code generators generate code; FWIW, personally I prefer the article's idea of interpreters over yours, and I speculate the article's is more representative of what most people think. I've never heard interpreters described the way you just did, as the part that interprets bytecode. (But I did find discussion of "bytecode interpreters" in the WP article, link below). Normally, an interpreter is a complete alternative to a compiler. Usually, an interpreter is more or less synonymous with a programming language "shell", or even the whole programming language. The Python shell would be an interpreter, for example. In my mind, virtual machines are what you call the thing that executes bytecode, not interpreters. I'd assume that someone talking about an "interpreter" without any other qualification was talking about a program that reads & runs a another program written in a scripting language. As time passes, these lines are getting blurrier. V8 is liberally mixing concepts from compilers and interpreters, so it's dangerous to draw hard lines. But you might be interested to double-check the broad strokes. https://en.m.wikipedia.org/wiki/Interpreter_(computing) https://en.m.wikipedia.org/wiki/Interpreter_(computing) > Abstraction is the wrong word here. The bytecode binary runs without modification on multiple hardware platforms. It's pretty reasonable to call that an abstraction of machine code. Because it is.

CalChris 9y ago
> Normally, an interpreter is a complete alternative to a compiler. Yes, that would be the Bill Gates MS Basic or Forth sense of interpreter. But it wouldn't be the post parsing, here's an AST, now what do we do with it sense. If they called V8 an interpreter (they call it an engine) I could see that although it would still seem archaic usage. But they're stitching Ignition on the side of V8 and calling that an interpreter which is just strange. > The bytecode binary runs without modification on multiple hardware platforms. It's pretty reasonable to call that an abstraction of machine code. No, that's portability onto multiple platforms. But the article said Bytecode is an abstraction of machine code. 'Abstraction of' vs 'runs on', these are two very different concepts.
- dahart 9y ago
  > Yes, that would be the Bill Gates MS Basic or Forth sense of interpreter. But it wouldn't be the post parsing, here's an AST, now what do we do with it sense. It's also the JavaScript, Python, Haskell, Perl, Ruby, bash, etc. etc. etc. sense of the word interpreter. You can use it to describe all languages that aren't compiled. You said interpreters "interpret bytecode". You claimed that a bytecode interpreter was the broadest definition of interpreter, and that saying the interpreter is what reads source JavaScript and turns it into bytecode was wrong. I disagree, and Wikipedia does too. Many, perhaps even most interpreters don't even involve bytecode at all. You're entitled to your opinion, but I guess just expect some pushback if you're going to try to correct people using your narrow, uncommon idea of what makes an interpreter. > No, that's portability onto multiple platforms. Normally when I'm talking about code with other people, "portable" means code you can re-compile for a platform, not that the binary runs without modification. But, sure, I'd agree that it's reasonable to call bytecode a mechanism for portability. The way it does that is by abstracting away a specific platform's assembly language in favor of one that runs on multiple platforms. People call programming languages like C & Python an abstraction of machine language. JavaScript's bytecode is just that - it's a low level programming language. And as such, it's abstracting the hardware. Virtual machines are an attempt to abstract the CPU specifics and have code that runs anywhere. > 'Abstraction of' vs 'runs on', these are very different concepts. I don't know what your definition of abstraction is, but based on your objections, it feels like you have a narrow and rigid idea that perhaps doesn't match the common usage. A function that takes a parameter is an abstraction of a block of code, just like any programming language that runs on multiple platforms is an abstraction of a specific CPU or machine language.

oscargrouch 9y ago

> Ignition, the interpreter, generates bytecode from this syntax tree. I guess she was addressing something more V8 specific. In the case of V8, the Ignition 'module' first generates the bytecode directly from the AST, and then in another step, interpret the generated bytecode. So, in this particular case it does both.