4 ms·

"The second trick is that Sparkplug doesn’t generate any intermediate representation (IR) like most compilers do. Instead, Sparkplug compiles directly to machin

"The second trick is that Sparkplug doesn’t generate any intermediate representation (IR) like most compilers do. Instead, Sparkplug compiles directly to machine code in a single linear pass over the bytecode, emitting code that matches the execution of that bytecode." Isn't bytecode an intermediate representation? https://en.wikipedia.org/wiki/Intermediate_representation https://en.wikipedia.org/wiki/Intermediate_representation Am I just being pedantic?

meheleventyone 5y ago
I guess the difference is that the bytecode is executed by the interpreter and an intermediate representation typically isn’t executable?
- SigmundA 5y ago
  Well some processors can execute Java byte code directly, and most of the time its jitted, however originally it was just interpreted.
  - Twirrim 5y ago
    Does anyone actually do that other than Transmeta back at the turn of the millenium?
    - SigmundA 5y ago
      Not really anymore but many phones had Jazelle capable processors in the mid 2000's: https://en.wikipedia.org/wiki/Java_processor https://en.wikipedia.org/wiki/Java_processor
    - deleted 5y ago
      [deleted]
- KMag 5y ago
  I think the most useful definition is that a program representation is an intermediate representation if its primary raison d'etre is as a starting point for building other program representations. (We assume source code has dual purposes of being edited/reviewed and also as the starting point for later program representations, so human-edited source code wouldn't be considered intermediate. On the other hand, JavaScript used as an implementation detail for some high-level language compiled to WASM would be considered an intermediate representation.) In this case, if they didn't have an interpreter, they'd probably use an abstract syntax tree or control flow graph as their common source of truth for their two compilers. So, the primary reason the bytecode exists is to be interpreted by the interpreter and therefore isn't intermediate.
chrisseaton 5y ago
In the compiler community, people usually use IR to mean something lower than bytecode, usually used as part of the compilation process itself rather than used for storage or when not actively compiling. IR is usually not intended for direct execution. (LLVM IR is an unusual exception therefore. Please don't 'well actually' me I'm trying to give a useful practical explanation.)
- Ar-Curunir 5y ago
  I thought IR was just the internal processing format used by a compiler, eg: MIR or LLVM IR, and so is at a level usually “higher” on the abstraction stack than assembly/bytecode, which can be seen as the primary outputs of a compiler
  - chrisseaton 5y ago
    We'd say it is 'lower' not 'higher' as it usually decomposes single higher-level compound operations into multiple simpler operations, and it makes things that were implicit explicit so they can be reasoned about. Usually more verbose therefore. Converting into IR is often called 'lowering'.
  - MikeHolman 5y ago
    IR is usually represented as a sort of linked list of instructions where you can easily move around instructions, add/remove them, and replace higher level instructions with lower level instructions as you go through compiler passes. At the end, the IR is a linked list of machine instructions, which gets written out to a code buffer as the last step. Bytecode is usually a buffer of high level instructions that is compact and fast to read (for the machine). Good for interpreting and holding the semantics of a program in a format that is more efficient than the source code, but it is usually not a good format for running compiler passes.
pizlonator 5y ago
For Sparkplug, bytecode is the input representation. But you’re right that bytecode is an intermediate representation of V8. So to me, whether bytecode is an IR or not depends on whether you’re talking about V8 as a whole or Sparkplug in particular. To me, an intermediate representation is what the compiler translates the input to other than machine code. Sparkplug goes straight from its input (bytecode) to machine code. So you’re not being too pedantic. It’s just that V8 has two compilers now, one that has an IR of its own (turbofan), and one that doesn’t (sparkplug). Lack of IR is one of the things (maybe the most important thing) that makes Sparkplug special. If you define IR in a way that means that bytecode is an IR then I don’t know how to easily articulate what it is that makes Sparkplug special.
johntb86 5y ago
It seems like Sparkplug per se isn't generating the IR. Instead it's the interpreter doing that.
IshKebab 5y ago
Yes but Sparkplug doesn't generate any bytecode.
titzer 5y ago
Even if you do consider bytecode to be an intermediate representation, the statement "Sparkplug doesn’t generate any intermediate representation (IR)" is true. It goes from one existing representation to machine code without creating a new one in the process.
- SigmundA 5y ago
  Right the javascript compiler is Ignition + Sparkplug with the bytecode as IR. Sparkplug doesn't parse or optimize, it relies on Ignition for that, so its not really a full compiler, its just the backend of a compiler. https://en.wikipedia.org/wiki/Compiler#Back_end https://en.wikipedia.org/wiki/Compiler#Back_end
  - masklinn 5y ago
    Well except ignition is first and foremost an interpreter, so sparkplug is a compiler backend welded onto an interpreter frontend.
    - SigmundA 5y ago
      Ignition optionally interprets but always parses javascript, optimizes and compiles bytecode. So IMO Ignition is primarily a compiler frontend that has an optional interpreter back end built in. I could see them splitting Ignition into a bytecode compiler and separate interpreter and give them separate names.
      - titzer 5y ago
        The V8 parser predates Ignition, so most V8 developers will consider it a separate subsystem and Ignition really to be just the bytecode format and interpreter for that bytecode. The parser was used to feed fullcodegen back in the day, and TurboFan also used to have an AST-to-TurboFan phase. Nowadays, I believe the only JavaScript path into TurboFan is actually through Ignition bytecode. TurboFan also has a frontend for Wasm bytecode (or viewed conversely, the Wasm engine has a TurboFan IR generator, since this lives in the wasm directory and is maintained by a subteam).

meheleventyone 5y ago

I guess the difference is that the bytecode is executed by the interpreter and an intermediate representation typically isn’t executable?

SigmundA 5y ago
Well some processors can execute Java byte code directly, and most of the time its jitted, however originally it was just interpreted.
- Twirrim 5y ago
  Does anyone actually do that other than Transmeta back at the turn of the millenium?
  - SigmundA 5y ago
    Not really anymore but many phones had Jazelle capable processors in the mid 2000's: https://en.wikipedia.org/wiki/Java_processor https://en.wikipedia.org/wiki/Java_processor
  - deleted 5y ago
    [deleted]
KMag 5y ago
I think the most useful definition is that a program representation is an intermediate representation if its primary raison d'etre is as a starting point for building other program representations. (We assume source code has dual purposes of being edited/reviewed and also as the starting point for later program representations, so human-edited source code wouldn't be considered intermediate. On the other hand, JavaScript used as an implementation detail for some high-level language compiled to WASM would be considered an intermediate representation.) In this case, if they didn't have an interpreter, they'd probably use an abstract syntax tree or control flow graph as their common source of truth for their two compilers. So, the primary reason the bytecode exists is to be interpreted by the interpreter and therefore isn't intermediate.

chrisseaton 5y ago

In the compiler community, people usually use IR to mean something lower than bytecode, usually used as part of the compilation process itself rather than used for storage or when not actively compiling. IR is usually not intended for direct execution. (LLVM IR is an unusual exception therefore. Please don't 'well actually' me I'm trying to give a useful practical explanation.)

Ar-Curunir 5y ago
I thought IR was just the internal processing format used by a compiler, eg: MIR or LLVM IR, and so is at a level usually “higher” on the abstraction stack than assembly/bytecode, which can be seen as the primary outputs of a compiler
- chrisseaton 5y ago
  We'd say it is 'lower' not 'higher' as it usually decomposes single higher-level compound operations into multiple simpler operations, and it makes things that were implicit explicit so they can be reasoned about. Usually more verbose therefore. Converting into IR is often called 'lowering'.
- MikeHolman 5y ago
  IR is usually represented as a sort of linked list of instructions where you can easily move around instructions, add/remove them, and replace higher level instructions with lower level instructions as you go through compiler passes. At the end, the IR is a linked list of machine instructions, which gets written out to a code buffer as the last step. Bytecode is usually a buffer of high level instructions that is compact and fast to read (for the machine). Good for interpreting and holding the semantics of a program in a format that is more efficient than the source code, but it is usually not a good format for running compiler passes.

pizlonator 5y ago

For Sparkplug, bytecode is the input representation. But you’re right that bytecode is an intermediate representation of V8. So to me, whether bytecode is an IR or not depends on whether you’re talking about V8 as a whole or Sparkplug in particular. To me, an intermediate representation is what the compiler translates the input to other than machine code. Sparkplug goes straight from its input (bytecode) to machine code. So you’re not being too pedantic. It’s just that V8 has two compilers now, one that has an IR of its own (turbofan), and one that doesn’t (sparkplug). Lack of IR is one of the things (maybe the most important thing) that makes Sparkplug special. If you define IR in a way that means that bytecode is an IR then I don’t know how to easily articulate what it is that makes Sparkplug special.

johntb86 5y ago

It seems like Sparkplug per se isn't generating the IR. Instead it's the interpreter doing that.

IshKebab 5y ago

Yes but Sparkplug doesn't generate any bytecode.

titzer 5y ago

Even if you do consider bytecode to be an intermediate representation, the statement "Sparkplug doesn’t generate any intermediate representation (IR)" is true. It goes from one existing representation to machine code without creating a new one in the process.

SigmundA 5y ago
Right the javascript compiler is Ignition + Sparkplug with the bytecode as IR. Sparkplug doesn't parse or optimize, it relies on Ignition for that, so its not really a full compiler, its just the backend of a compiler. https://en.wikipedia.org/wiki/Compiler#Back_end https://en.wikipedia.org/wiki/Compiler#Back_end
- masklinn 5y ago
  Well except ignition is first and foremost an interpreter, so sparkplug is a compiler backend welded onto an interpreter frontend.
  - SigmundA 5y ago
    Ignition optionally interprets but always parses javascript, optimizes and compiles bytecode. So IMO Ignition is primarily a compiler frontend that has an optional interpreter back end built in. I could see them splitting Ignition into a bytecode compiler and separate interpreter and give them separate names.
    - titzer 5y ago
      The V8 parser predates Ignition, so most V8 developers will consider it a separate subsystem and Ignition really to be just the bytecode format and interpreter for that bytecode. The parser was used to feed fullcodegen back in the day, and TurboFan also used to have an AST-to-TurboFan phase. Nowadays, I believe the only JavaScript path into TurboFan is actually through Ignition bytecode. TurboFan also has a frontend for Wasm bytecode (or viewed conversely, the Wasm engine has a TurboFan IR generator, since this lives in the wasm directory and is maintained by a subteam).