Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 15:43:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibJS/Bytecode/Op.h

591 lines
16 KiB
C
Raw Normal View History

LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
/*
* Copyright (c) 2021, Andreas Kling <kling@serenityos.org>
LibJS: Add bytecode generation for BinaryOp::In
2021-06-07 21:13:37 +01:00
* Copyright (c) 2021, Linus Groh <linusg@serenityos.org>
LibJS: Generate bytecode for throw statements
2021-06-09 18:18:56 +02:00
* Copyright (c) 2021, Gunnar Beutner <gbeutner@serenityos.org>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibJS: Implement bytecode generation for BigInts
2021-06-08 07:59:25 +02:00
#include <LibCrypto/BigInt/SignedBigInteger.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
#include <LibJS/Bytecode/Instruction.h>
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
#include <LibJS/Bytecode/Label.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
#include <LibJS/Bytecode/Register.h>
LibJS: Store strings in a string table Instead of using Strings in the bytecode ops this adds a global string table to the Executable struct which individual operations can refer to using indices. This brings bytecode ops one step closer to being pointer free.
2021-06-09 10:02:01 +02:00
#include <LibJS/Bytecode/StringTable.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
#include <LibJS/Heap/Cell.h>
LibJS: Generate bytecode for entering nested lexical environments This adds a new PushLexicalEnvironment instruction that creates a new LexicalEnvironment and pushes it on the VM's scope stack. There is no corresponding PopLexicalEnvironment instruction yet, so this will behave incorrectly with let/const scopes for example.
2021-06-10 22:12:21 +02:00
#include <LibJS/Runtime/ScopeObject.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
#include <LibJS/Runtime/Value.h>
namespace JS::Bytecode::Op {
class Load final : public Instruction {
public:
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
explicit Load(Register src)
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
: Instruction(Type::Load)
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
, m_src(src)
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
private:
Register m_src;
};
class LoadImmediate final : public Instruction {
public:
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
explicit LoadImmediate(Value value)
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
: Instruction(Type::LoadImmediate)
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
, m_value(value)
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
private:
Value m_value;
};
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
class Store final : public Instruction {
LibJS: Make sure that if expressions yield the correct value When evaluated as an expression "if (true) { 3 } else { 5 }" should yield 3. This updates the bytecode interpreter to make it so.
2021-06-07 22:05:09 +02:00
public:
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
explicit Store(Register dst)
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
: Instruction(Type::Store)
LibJS: Make sure that if expressions yield the correct value When evaluated as an expression "if (true) { 3 } else { 5 }" should yield 3. This updates the bytecode interpreter to make it so.
2021-06-07 22:05:09 +02:00
, m_dst(dst)
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Make sure that if expressions yield the correct value When evaluated as an expression "if (true) { 3 } else { 5 }" should yield 3. This updates the bytecode interpreter to make it so.
2021-06-07 22:05:09 +02:00
private:
Register m_dst;
};
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
#define JS_ENUMERATE_COMMON_BINARY_OPS(O) \
O(Add, add) \
O(Sub, sub) \
O(Mul, mul) \
O(Div, div) \
O(Exp, exp) \
O(Mod, mod) \
O(In, in) \
O(InstanceOf, instance_of) \
O(GreaterThan, greater_than) \
O(GreaterThanEquals, greater_than_equals) \
O(LessThan, less_than) \
O(LessThanEquals, less_than_equals) \
O(AbstractInequals, abstract_inequals) \
O(AbstractEquals, abstract_equals) \
O(TypedInequals, typed_inequals) \
O(TypedEquals, typed_equals) \
O(BitwiseAnd, bitwise_and) \
O(BitwiseOr, bitwise_or) \
O(BitwiseXor, bitwise_xor) \
O(LeftShift, left_shift) \
O(RightShift, right_shift) \
O(UnsignedRightShift, unsigned_right_shift)
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
#define JS_DECLARE_COMMON_BINARY_OP(OpTitleCase, op_snake_case) \
class OpTitleCase final : public Instruction { \
public: \
explicit OpTitleCase(Register lhs_reg) \
: Instruction(Type::OpTitleCase) \
, m_lhs_reg(lhs_reg) \
{ \
} \
\
void execute_impl(Bytecode::Interpreter&) const; \
String to_string_impl(Bytecode::Executable const&) const; \
\
private: \
Register m_lhs_reg; \
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
};
JS_ENUMERATE_COMMON_BINARY_OPS(JS_DECLARE_COMMON_BINARY_OP)
#undef JS_DECLARE_COMMON_BINARY_OP
#define JS_ENUMERATE_COMMON_UNARY_OPS(O) \
O(BitwiseNot, bitwise_not) \
O(Not, not_) \
O(UnaryPlus, unary_plus) \
O(UnaryMinus, unary_minus) \
O(Typeof, typeof_)
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
#define JS_DECLARE_COMMON_UNARY_OP(OpTitleCase, op_snake_case) \
class OpTitleCase final : public Instruction { \
public: \
OpTitleCase() \
: Instruction(Type::OpTitleCase) \
{ \
} \
\
void execute_impl(Bytecode::Interpreter&) const; \
String to_string_impl(Bytecode::Executable const&) const; \
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
};
JS_ENUMERATE_COMMON_UNARY_OPS(JS_DECLARE_COMMON_UNARY_OP)
#undef JS_DECLARE_COMMON_UNARY_OP
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
class NewString final : public Instruction {
public:
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
explicit NewString(StringTableIndex string)
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
: Instruction(Type::NewString)
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
, m_string(string)
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
private:
LibJS: Store strings in a string table Instead of using Strings in the bytecode ops this adds a global string table to the Executable struct which individual operations can refer to using indices. This brings bytecode ops one step closer to being pointer free.
2021-06-09 10:02:01 +02:00
StringTableIndex m_string;
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
};
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 20:30:23 +02:00
class NewObject final : public Instruction {
public:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
NewObject()
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
: Instruction(Type::NewObject)
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 20:30:23 +02:00
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 20:30:23 +02:00
};
LibJS: Implement bytecode generation for BigInts
2021-06-08 07:59:25 +02:00
class NewBigInt final : public Instruction {
public:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
explicit NewBigInt(Crypto::SignedBigInteger bigint)
LibJS: Implement bytecode generation for BigInts
2021-06-08 07:59:25 +02:00
: Instruction(Type::NewBigInt)
, m_bigint(move(bigint))
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Implement bytecode generation for BigInts
2021-06-08 07:59:25 +02:00
private:
Crypto::SignedBigInteger m_bigint;
};
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
// NOTE: This instruction is variable-width depending on the number of elements!
class NewArray final : public Instruction {
public:
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
explicit NewArray(Vector<Register> const& elements)
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
: Instruction(Type::NewArray)
, m_element_count(elements.size())
{
for (size_t i = 0; i < m_element_count; ++i)
m_elements[i] = elements[i];
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
size_t length_impl() const { return sizeof(*this) + sizeof(Register) * m_element_count; }
LibJS: Add missing length() method for NewArray
2021-06-12 05:49:09 +02:00
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
private:
size_t m_element_count { 0 };
Register m_elements[];
};
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
class ConcatString final : public Instruction {
public:
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
explicit ConcatString(Register lhs)
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
: Instruction(Type::ConcatString)
, m_lhs(lhs)
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
private:
Register m_lhs;
};
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
class SetVariable final : public Instruction {
public:
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
explicit SetVariable(StringTableIndex identifier)
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
: Instruction(Type::SetVariable)
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
, m_identifier(identifier)
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
private:
LibJS: Store strings in a string table Instead of using Strings in the bytecode ops this adds a global string table to the Executable struct which individual operations can refer to using indices. This brings bytecode ops one step closer to being pointer free.
2021-06-09 10:02:01 +02:00
StringTableIndex m_identifier;
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
};
class GetVariable final : public Instruction {
public:
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
explicit GetVariable(StringTableIndex identifier)
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
: Instruction(Type::GetVariable)
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
, m_identifier(identifier)
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
private:
LibJS: Store strings in a string table Instead of using Strings in the bytecode ops this adds a global string table to the Executable struct which individual operations can refer to using indices. This brings bytecode ops one step closer to being pointer free.
2021-06-09 10:02:01 +02:00
StringTableIndex m_identifier;
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
};
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 21:03:53 +02:00
class GetById final : public Instruction {
public:
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
explicit GetById(StringTableIndex property)
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
: Instruction(Type::GetById)
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
, m_property(property)
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 21:03:53 +02:00
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 21:03:53 +02:00
private:
LibJS: Store strings in a string table Instead of using Strings in the bytecode ops this adds a global string table to the Executable struct which individual operations can refer to using indices. This brings bytecode ops one step closer to being pointer free.
2021-06-09 10:02:01 +02:00
StringTableIndex m_property;
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 21:03:53 +02:00
};
LibJS: Add PutById bytecode instruction for object property assignment Note that this is only used for non-computed accesses. Computed access is not yet implemented. :^)
2021-06-04 20:47:07 +02:00
class PutById final : public Instruction {
public:
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
explicit PutById(Register base, StringTableIndex property)
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
: Instruction(Type::PutById)
, m_base(base)
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
, m_property(property)
LibJS: Add PutById bytecode instruction for object property assignment Note that this is only used for non-computed accesses. Computed access is not yet implemented. :^)
2021-06-04 20:47:07 +02:00
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add PutById bytecode instruction for object property assignment Note that this is only used for non-computed accesses. Computed access is not yet implemented. :^)
2021-06-04 20:47:07 +02:00
private:
Register m_base;
LibJS: Store strings in a string table Instead of using Strings in the bytecode ops this adds a global string table to the Executable struct which individual operations can refer to using indices. This brings bytecode ops one step closer to being pointer free.
2021-06-09 10:02:01 +02:00
StringTableIndex m_property;
LibJS: Add PutById bytecode instruction for object property assignment Note that this is only used for non-computed accesses. Computed access is not yet implemented. :^)
2021-06-04 20:47:07 +02:00
};
LibJS: Basic bytecode support for computed member expressions Expressions like foo[1 + 2] now work, and you can assign to them as well! :^)
2021-06-11 00:35:25 +02:00
class GetByValue final : public Instruction {
public:
explicit GetByValue(Register base)
: Instruction(Type::GetByValue)
, m_base(base)
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Basic bytecode support for computed member expressions Expressions like foo[1 + 2] now work, and you can assign to them as well! :^)
2021-06-11 00:35:25 +02:00
private:
Register m_base;
};
class PutByValue final : public Instruction {
public:
PutByValue(Register base, Register property)
: Instruction(Type::PutByValue)
, m_base(base)
, m_property(property)
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Basic bytecode support for computed member expressions Expressions like foo[1 + 2] now work, and you can assign to them as well! :^)
2021-06-11 00:35:25 +02:00
private:
Register m_base;
Register m_property;
};
LibJS: Make JumpIf{True,False,Nullish} inherit from Jump This saves a few lines in LogicalExpression::generate_bytecode.
2021-06-08 11:28:27 +02:00
class Jump : public Instruction {
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
public:
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
constexpr static bool IsTerminator = true;
explicit Jump(Type type, Optional<Label> taken_target = {}, Optional<Label> nontaken_target = {})
LibJS: Make JumpIf{True,False,Nullish} inherit from Jump This saves a few lines in LogicalExpression::generate_bytecode.
2021-06-08 11:28:27 +02:00
: Instruction(type)
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
, m_true_target(move(taken_target))
, m_false_target(move(nontaken_target))
LibJS: Make JumpIf{True,False,Nullish} inherit from Jump This saves a few lines in LogicalExpression::generate_bytecode.
2021-06-08 11:28:27 +02:00
{
}
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
explicit Jump(Optional<Label> taken_target = {}, Optional<Label> nontaken_target = {})
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
: Instruction(Type::Jump)
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
, m_true_target(move(taken_target))
, m_false_target(move(nontaken_target))
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
{
}
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
void set_targets(Optional<Label> true_target, Optional<Label> false_target)
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
{
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
m_true_target = move(true_target);
m_false_target = move(false_target);
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
protected:
Optional<Label> m_true_target;
Optional<Label> m_false_target;
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
};
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
class JumpConditional final : public Jump {
LibJS: Generate bytecode for do...while statements :^) This was quite straightforward using the same label/jump machinery that we added for while statements. The main addition here is a new JumpIfTrue bytecode instruction.
2021-06-04 12:20:44 +02:00
public:
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
explicit JumpConditional(Optional<Label> true_target = {}, Optional<Label> false_target = {})
: Jump(Type::JumpConditional, move(true_target), move(false_target))
LibJS: Generate bytecode for do...while statements :^) This was quite straightforward using the same label/jump machinery that we added for while statements. The main addition here is a new JumpIfTrue bytecode instruction.
2021-06-04 12:20:44 +02:00
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Generate bytecode for do...while statements :^) This was quite straightforward using the same label/jump machinery that we added for while statements. The main addition here is a new JumpIfTrue bytecode instruction.
2021-06-04 12:20:44 +02:00
};
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
class JumpNullish final : public Jump {
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
public:
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
explicit JumpNullish(Optional<Label> true_target = {}, Optional<Label> false_target = {})
: Jump(Type::JumpNullish, move(true_target), move(false_target))
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
};
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
// NOTE: This instruction is variable-width depending on the number of arguments!
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
class Call final : public Instruction {
public:
LibJS: Very basic support for "new" construction in bytecode VM This patch adds a CallType to the Bytecode::Op::Call instruction, which can be either Call or Construct. We then generate Construct calls for the NewExpression AST node. When executed, these get fed into VM::construct().
2021-06-10 23:01:49 +02:00
enum class CallType {
Call,
Construct,
};
Call(CallType type, Register callee, Register this_value, Vector<Register> const& arguments)
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
: Instruction(Type::Call)
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
, m_callee(callee)
, m_this_value(this_value)
LibJS: Very basic support for "new" construction in bytecode VM This patch adds a CallType to the Bytecode::Op::Call instruction, which can be either Call or Construct. We then generate Construct calls for the NewExpression AST node. When executed, these get fed into VM::construct().
2021-06-10 23:01:49 +02:00
, m_type(type)
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
, m_argument_count(arguments.size())
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
{
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
for (size_t i = 0; i < m_argument_count; ++i)
m_arguments[i] = arguments[i];
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
size_t length_impl() const { return sizeof(*this) + sizeof(Register) * m_argument_count; }
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
private:
Register m_callee;
Register m_this_value;
LibJS: Very basic support for "new" construction in bytecode VM This patch adds a CallType to the Bytecode::Op::Call instruction, which can be either Call or Construct. We then generate Construct calls for the NewExpression AST node. When executed, these get fed into VM::construct().
2021-06-10 23:01:49 +02:00
CallType m_type;
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
size_t m_argument_count { 0 };
Register m_arguments[];
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
};
LibJS: Perform function instantiation in bytecode This replaces Bytecode::Op::EnterScope with a new NewFunction op that instantiates a ScriptFunction from a given FunctionNode (AST). This is then used to instantiate the local functions directly from bytecode when entering a ScopeNode. :^)
2021-06-10 00:49:23 +02:00
class NewFunction final : public Instruction {
LibJS: Add a new EnterScope bytecode instruction This is intended to perform the same duties as enter_scope() does in the AST tree-walk interpreter: - Hoisted function declaration processing - Hoisted variable declaration processing - ... maybe more This first cut only implements the function declaration processing.
2021-06-05 15:14:09 +02:00
public:
LibJS: Perform function instantiation in bytecode This replaces Bytecode::Op::EnterScope with a new NewFunction op that instantiates a ScriptFunction from a given FunctionNode (AST). This is then used to instantiate the local functions directly from bytecode when entering a ScopeNode. :^)
2021-06-10 00:49:23 +02:00
explicit NewFunction(FunctionNode const& function_node)
: Instruction(Type::NewFunction)
, m_function_node(function_node)
LibJS: Add a new EnterScope bytecode instruction This is intended to perform the same duties as enter_scope() does in the AST tree-walk interpreter: - Hoisted function declaration processing - Hoisted variable declaration processing - ... maybe more This first cut only implements the function declaration processing.
2021-06-05 15:14:09 +02:00
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a new EnterScope bytecode instruction This is intended to perform the same duties as enter_scope() does in the AST tree-walk interpreter: - Hoisted function declaration processing - Hoisted variable declaration processing - ... maybe more This first cut only implements the function declaration processing.
2021-06-05 15:14:09 +02:00
private:
LibJS: Perform function instantiation in bytecode This replaces Bytecode::Op::EnterScope with a new NewFunction op that instantiates a ScriptFunction from a given FunctionNode (AST). This is then used to instantiate the local functions directly from bytecode when entering a ScopeNode. :^)
2021-06-10 00:49:23 +02:00
FunctionNode const& m_function_node;
LibJS: Add a new EnterScope bytecode instruction This is intended to perform the same duties as enter_scope() does in the AST tree-walk interpreter: - Hoisted function declaration processing - Hoisted variable declaration processing - ... maybe more This first cut only implements the function declaration processing.
2021-06-05 15:14:09 +02:00
};
LibJS: Compile ScriptFunctions into bytecode and run them that way :^) If there's a current Bytecode::Interpreter in action, ScriptFunction will now compile itself into bytecode and execute in that context. This patch also adds the Return bytecode instruction so that we can actually return values from called functions. :^) Return values are propagated from callee to caller via the caller's $0 register. Bytecode::Interpreter now keeps a stack of register "windows". These are not very efficient, but it should be pretty straightforward to convert them to e.g a sliding register window architecture later on. This is pretty dang cool! :^)
2021-06-05 15:53:36 +02:00
class Return final : public Instruction {
public:
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
constexpr static bool IsTerminator = true;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
Return()
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
: Instruction(Type::Return)
LibJS: Compile ScriptFunctions into bytecode and run them that way :^) If there's a current Bytecode::Interpreter in action, ScriptFunction will now compile itself into bytecode and execute in that context. This patch also adds the Return bytecode instruction so that we can actually return values from called functions. :^) Return values are propagated from callee to caller via the caller's $0 register. Bytecode::Interpreter now keeps a stack of register "windows". These are not very efficient, but it should be pretty straightforward to convert them to e.g a sliding register window architecture later on. This is pretty dang cool! :^)
2021-06-05 15:53:36 +02:00
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Compile ScriptFunctions into bytecode and run them that way :^) If there's a current Bytecode::Interpreter in action, ScriptFunction will now compile itself into bytecode and execute in that context. This patch also adds the Return bytecode instruction so that we can actually return values from called functions. :^) Return values are propagated from callee to caller via the caller's $0 register. Bytecode::Interpreter now keeps a stack of register "windows". These are not very efficient, but it should be pretty straightforward to convert them to e.g a sliding register window architecture later on. This is pretty dang cool! :^)
2021-06-05 15:53:36 +02:00
};
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
class Increment final : public Instruction {
public:
Increment()
: Instruction(Type::Increment)
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
};
class Decrement final : public Instruction {
public:
Decrement()
: Instruction(Type::Decrement)
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
};
LibJS: Generate bytecode for throw statements
2021-06-09 18:18:56 +02:00
class Throw final : public Instruction {
public:
constexpr static bool IsTerminator = true;
Throw()
: Instruction(Type::Throw)
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Generate bytecode for throw statements
2021-06-09 18:18:56 +02:00
};
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
class EnterUnwindContext final : public Instruction {
public:
LibJS: Make EnterUnwindContext a terminator op Otherwise a basic block could have multiple outgoing edges without having much reason to do so.
2021-06-13 20:39:40 +04:30
constexpr static bool IsTerminator = true;
EnterUnwindContext(Label entry_point, Optional<Label> handler_target, Optional<Label> finalizer_target)
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
: Instruction(Type::EnterUnwindContext)
LibJS: Make EnterUnwindContext a terminator op Otherwise a basic block could have multiple outgoing edges without having much reason to do so.
2021-06-13 20:39:40 +04:30
, m_entry_point(move(entry_point))
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
, m_handler_target(move(handler_target))
, m_finalizer_target(move(finalizer_target))
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
private:
LibJS: Make EnterUnwindContext a terminator op Otherwise a basic block could have multiple outgoing edges without having much reason to do so.
2021-06-13 20:39:40 +04:30
Label m_entry_point;
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
Optional<Label> m_handler_target;
Optional<Label> m_finalizer_target;
};
class LeaveUnwindContext final : public Instruction {
public:
LeaveUnwindContext()
: Instruction(Type::LeaveUnwindContext)
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
};
class ContinuePendingUnwind final : public Instruction {
public:
constexpr static bool IsTerminator = true;
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
explicit ContinuePendingUnwind(Label resume_target)
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
: Instruction(Type::ContinuePendingUnwind)
, m_resume_target(resume_target)
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
private:
Label m_resume_target;
};
LibJS: Generate bytecode for entering nested lexical environments This adds a new PushLexicalEnvironment instruction that creates a new LexicalEnvironment and pushes it on the VM's scope stack. There is no corresponding PopLexicalEnvironment instruction yet, so this will behave incorrectly with let/const scopes for example.
2021-06-10 22:12:21 +02:00
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
class Yield final : public Instruction {
public:
constexpr static bool IsTerminator = true;
explicit Yield(Label continuation_label)
: Instruction(Type::Yield)
, m_continuation_label(continuation_label)
{
}
explicit Yield(std::nullptr_t)
: Instruction(Type::Yield)
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
private:
Optional<Label> m_continuation_label;
};
LibJS: Generate bytecode for entering nested lexical environments This adds a new PushLexicalEnvironment instruction that creates a new LexicalEnvironment and pushes it on the VM's scope stack. There is no corresponding PopLexicalEnvironment instruction yet, so this will behave incorrectly with let/const scopes for example.
2021-06-10 22:12:21 +02:00
class PushLexicalEnvironment final : public Instruction {
public:
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
explicit PushLexicalEnvironment(HashMap<u32, Variable> variables)
LibJS: Generate bytecode for entering nested lexical environments This adds a new PushLexicalEnvironment instruction that creates a new LexicalEnvironment and pushes it on the VM's scope stack. There is no corresponding PopLexicalEnvironment instruction yet, so this will behave incorrectly with let/const scopes for example.
2021-06-10 22:12:21 +02:00
: Instruction(Type::PushLexicalEnvironment)
, m_variables(move(variables))
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Generate bytecode for entering nested lexical environments This adds a new PushLexicalEnvironment instruction that creates a new LexicalEnvironment and pushes it on the VM's scope stack. There is no corresponding PopLexicalEnvironment instruction yet, so this will behave incorrectly with let/const scopes for example.
2021-06-10 22:12:21 +02:00
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
private:
LibJS: Generate bytecode for entering nested lexical environments This adds a new PushLexicalEnvironment instruction that creates a new LexicalEnvironment and pushes it on the VM's scope stack. There is no corresponding PopLexicalEnvironment instruction yet, so this will behave incorrectly with let/const scopes for example.
2021-06-10 22:12:21 +02:00
HashMap<u32, Variable> m_variables;
};
LibJS: Add LoadArgument bytecode instruction for fast argument access This is generated for Identifier nodes that represent a function argument variable. It loads a given argument index from the current call frame into the accumulator.
2021-06-14 09:37:35 +02:00
class LoadArgument final : public Instruction {
public:
explicit LoadArgument(size_t index)
: Instruction(Type::LoadArgument)
, m_index(index)
{
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add LoadArgument bytecode instruction for fast argument access This is generated for Identifier nodes that represent a function argument variable. It loads a given argument index from the current call frame into the accumulator.
2021-06-14 09:37:35 +02:00
private:
size_t m_index { 0 };
};
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
}
LibJS: Move Bytecode::Instruction::execute() to the Op.h header ..and make sure it always gets inlined in the interpreter loop.
2021-06-09 09:19:34 +02:00
namespace JS::Bytecode {
ALWAYS_INLINE void Instruction::execute(Bytecode::Interpreter& interpreter) const
{
#define __BYTECODE_OP(op) \
case Instruction::Type::op: \
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
return static_cast<Bytecode::Op::op const&>(*this).execute_impl(interpreter);
LibJS: Move Bytecode::Instruction::execute() to the Op.h header ..and make sure it always gets inlined in the interpreter loop.
2021-06-09 09:19:34 +02:00
switch (type()) {
ENUMERATE_BYTECODE_OPS(__BYTECODE_OP)
default:
VERIFY_NOT_REACHED();
}
#undef __BYTECODE_OP
}
LibJS: Move Instruction::length() to the Op.h header Make sure this gets inlined as well, as it's used by the bytecode stream iterator and thus extremely hot.
2021-06-09 09:23:38 +02:00
ALWAYS_INLINE size_t Instruction::length() const
{
if (type() == Type::Call)
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
return static_cast<Op::Call const&>(*this).length_impl();
LibJS: Move Instruction::length() to the Op.h header Make sure this gets inlined as well, as it's used by the bytecode stream iterator and thus extremely hot.
2021-06-09 09:23:38 +02:00
else if (type() == Type::NewArray)
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
return static_cast<Op::NewArray const&>(*this).length_impl();
LibJS: Move Instruction::length() to the Op.h header Make sure this gets inlined as well, as it's used by the bytecode stream iterator and thus extremely hot.
2021-06-09 09:23:38 +02:00
#define __BYTECODE_OP(op) \
case Type::op: \
return sizeof(Op::op);
switch (type()) {
ENUMERATE_BYTECODE_OPS(__BYTECODE_OP)
default:
VERIFY_NOT_REACHED();
}
#undef __BYTECODE_OP
}
LibJS: Move Bytecode::Instruction::execute() to the Op.h header ..and make sure it always gets inlined in the interpreter loop.
2021-06-09 09:19:34 +02:00
}
Reference in a new issue Copy permalink