Hacker News Reader

Comment by SigmundA | Hacker News Reader

"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

Am I just being pedantic?

View on HN

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.

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

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

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.

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

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.

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

Well except ignition is first and foremost an interpreter, so sparkplug is a compiler backend welded onto an interpreter frontend.

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.

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

So does the parser generate byte code or ignition? Is ignition just an interpreter or is it a byte code generator too? Does ignition take byte code or is it fed the ast from the parser to generate byte code?

"Ignition" was the codename for the entire interpreter project, including both the Ignition compiler and the Ignition interpreter. So the answer to your question is "yes".

The parser produces an AST, which is an in-memory data structure that is a tree. Ignition (in src/interpreter) has a visitor that walks over the AST and generates bytecode.

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

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.

Well some processors can execute Java byte code directly, and most of the time its jitted, however originally it was just interpreted.

Does anyone actually do that other than Transmeta back at the turn of the millenium?

Not really anymore but many phones had Jazelle capable processors in the mid 2000's:

https://en.wikipedia.org/wiki/Java_processor

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

Yes but Sparkplug doesn't generate any bytecode.

Reply on news.ycombinator.com