beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-25 09:00:22 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 7
ladybird/Userland/Libraries/LibJS/Bytecode/Op.h

1025 lines
31 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 08:46:30 +00:00
/*
* Copyright (c) 2021, Andreas Kling <kling@serenityos.org>
LibJS: Add bytecode generation for BinaryOp::In
2021-06-07 20:13:37 +00:00
* Copyright (c) 2021, Linus Groh <linusg@serenityos.org>
LibJS: Generate bytecode for throw statements
2021-06-09 16:18:56 +00: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 08:46:30 +00:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibJS: Align Instructions as void* and roundup variably sized ones sizes Both is indeed needed, the standard alignment would have been 4, but some Instructions, like Jumps need an alignment of 8 Fixes #12127.
2022-09-09 14:47:42 +00:00
#include <AK/StdLibExtras.h>
LibJS: Implement bytecode generation for BigInts
2021-06-08 05:59:25 +00:00
#include <LibCrypto/BigInt/SignedBigInteger.h>
LibJS: Add a separate "identifier table" to bytecode executables This is a specialized string table for storing identifiers only. Identifiers are always FlyStrings, which makes many common operations faster by allowing O(1) comparison.
2021-10-24 13:34:30 +00:00
#include <LibJS/Bytecode/IdentifierTable.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 08:46:30 +00: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 10:07:38 +00: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 08:46:30 +00: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 08:02:01 +00: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 08:46:30 +00:00
#include <LibJS/Heap/Cell.h>
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 10:24:46 +00:00
#include <LibJS/Runtime/Environment.h>
LibJS: Add the "fast non-local access" optimization to the bytecode VM The GetVariable bytecode op now caches environment coordinates for fast cross-scope variable lookup.
2021-10-24 13:36:24 +00:00
#include <LibJS/Runtime/EnvironmentCoordinate.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 08:46:30 +00:00
#include <LibJS/Runtime/Value.h>
LibJS: Avoid unnecessary ToObject conversion when resolving references When performing GetValue on a primitive type we do not need to perform the ToObject conversion as it will resolve to a property on the prototype object. To avoid this we skip the initial ToObject conversion on the base value as it only serves to get the primitive's boxed prototype. We further specialize on PrimitiveString in order to get efficient behaviour behaviour for the direct properties. Depending on the tests anywhere from 20 to 60%, with significant loop overhead.
2022-02-12 08:48:23 +00:00
#include <LibJS/Runtime/ValueTraits.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 08:46:30 +00:00
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 09:22:46 +00: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 13:12:43 +00: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-08 03:58:36 +00:00
, m_src(src)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock 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-08 03:58:36 +00: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 09:22:46 +00: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-08 03:58:36 +00: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 08:46:30 +00:00
, m_value(value)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock 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 08:46:30 +00: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-08 03:58:36 +00: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 20:05:09 +00:00
public:
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 09:22:46 +00: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-08 03:58:36 +00: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 20:05:09 +00:00
, m_dst(dst)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock 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 20:05:09 +00:00
private:
Register m_dst;
};
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 21:08:35 +00: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) \
LibJS: Rename {Abstract,Typed => Loosely,Strictly}{Equals,Inequals} This affects the AST's BinaryOp enum as well as the Bytecode's ENUMERATE_BYTECODE_OPS and JS_ENUMERATE_COMMON_BINARY_OPS macros.
2021-09-23 22:06:10 +00:00
O(LooselyInequals, abstract_inequals) \
O(LooselyEquals, abstract_equals) \
O(StrictlyInequals, typed_inequals) \
O(StrictlyEquals, typed_equals) \
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 21:08:35 +00:00
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: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
#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) \
{ \
} \
\
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const; \
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
String to_string_impl(Bytecode::Executable const&) const; \
void replace_references_impl(BasicBlock const&, BasicBlock const&) { } \
\
private: \
Register m_lhs_reg; \
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 21:08:35 +00: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: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
#define JS_DECLARE_COMMON_UNARY_OP(OpTitleCase, op_snake_case) \
class OpTitleCase final : public Instruction { \
public: \
OpTitleCase() \
: Instruction(Type::OpTitleCase) \
{ \
} \
\
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const; \
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
String to_string_impl(Bytecode::Executable const&) const; \
void replace_references_impl(BasicBlock const&, BasicBlock const&) { } \
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 21:08:35 +00: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 18:53:47 +00: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 16:26:32 +00: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 09:22:46 +00: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 13:12:43 +00: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 09:22:46 +00: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 16:26:32 +00:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock 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 16:26:32 +00: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 08:02:01 +00: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 16:26:32 +00:00
};
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 18:30:23 +00: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-08 03:58:36 +00: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 13:12:43 +00:00
: Instruction(Type::NewObject)
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 18:30:23 +00:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 18:30:23 +00:00
};
LibJS: Add bytecode support for regexp literals
2021-06-20 00:17:40 +00:00
class NewRegExp final : public Instruction {
public:
NewRegExp(StringTableIndex source_index, StringTableIndex flags_index)
: Instruction(Type::NewRegExp)
, m_source_index(source_index)
, m_flags_index(flags_index)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
LibJS: Add bytecode support for regexp literals
2021-06-20 00:17:40 +00:00
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
private:
StringTableIndex m_source_index;
StringTableIndex m_flags_index;
};
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 22:30:32 +00:00
// NOTE: This instruction is variable-width depending on the number of excluded names
class CopyObjectExcludingProperties final : public Instruction {
public:
CopyObjectExcludingProperties(Register from_object, Vector<Register> const& excluded_names)
: Instruction(Type::CopyObjectExcludingProperties)
, m_from_object(from_object)
, m_excluded_names_count(excluded_names.size())
{
for (size_t i = 0; i < m_excluded_names_count; i++)
m_excluded_names[i] = excluded_names[i];
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 22:30:32 +00:00
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
size_t length_impl() const { return sizeof(*this) + sizeof(Register) * m_excluded_names_count; }
private:
Register m_from_object;
size_t m_excluded_names_count { 0 };
Register m_excluded_names[];
};
LibJS: Implement bytecode generation for BigInts
2021-06-08 05:59:25 +00: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-08 03:58:36 +00:00
explicit NewBigInt(Crypto::SignedBigInteger bigint)
LibJS: Implement bytecode generation for BigInts
2021-06-08 05:59:25 +00:00
: Instruction(Type::NewBigInt)
, m_bigint(move(bigint))
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
LibJS: Implement bytecode generation for BigInts
2021-06-08 05:59:25 +00:00
private:
Crypto::SignedBigInteger m_bigint;
};
LibJS: Generate bytecode for array expressions
2021-06-08 21:06:52 +00:00
// NOTE: This instruction is variable-width depending on the number of elements!
class NewArray final : public Instruction {
public:
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 21:06:26 +00:00
NewArray()
: Instruction(Type::NewArray)
, m_element_count(0)
{
}
LibJS: Use ranges instead of specifying all registers for NewArray Listing all the registers will lead to the inability to allocate enough space in one basic block (as there can be an arbitrary number of registers used), instead switch to specifying the range of registers used and save a lot of space in the process.
2022-03-14 14:48:42 +00:00
explicit NewArray(AK::Array<Register, 2> const& elements_range)
LibJS: Generate bytecode for array expressions
2021-06-08 21:06:52 +00:00
: Instruction(Type::NewArray)
LibJS: Use ranges instead of specifying all registers for NewArray Listing all the registers will lead to the inability to allocate enough space in one basic block (as there can be an arbitrary number of registers used), instead switch to specifying the range of registers used and save a lot of space in the process.
2022-03-14 14:48:42 +00:00
, m_element_count(elements_range[1].index() - elements_range[0].index() + 1)
LibJS: Generate bytecode for array expressions
2021-06-08 21:06:52 +00:00
{
LibJS: Use ranges instead of specifying all registers for NewArray Listing all the registers will lead to the inability to allocate enough space in one basic block (as there can be an arbitrary number of registers used), instead switch to specifying the range of registers used and save a lot of space in the process.
2022-03-14 14:48:42 +00:00
m_elements[0] = elements_range[0];
m_elements[1] = elements_range[1];
LibJS: Generate bytecode for array expressions
2021-06-08 21:06:52 +00:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
LibJS: Generate bytecode for array expressions
2021-06-08 21:06:52 +00:00
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
size_t length_impl() const
{
LibJS: Use ranges instead of specifying all registers for NewArray Listing all the registers will lead to the inability to allocate enough space in one basic block (as there can be an arbitrary number of registers used), instead switch to specifying the range of registers used and save a lot of space in the process.
2022-03-14 14:48:42 +00:00
return sizeof(*this) + sizeof(Register) * (m_element_count == 0 ? 0 : 2);
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
}
LibJS: Add missing length() method for NewArray
2021-06-12 03:49:09 +00:00
LibJS: Generate bytecode for array expressions
2021-06-08 21:06:52 +00:00
private:
size_t m_element_count { 0 };
Register m_elements[];
};
LibJS: Add support for SpreadExpressions in array literals for bytecode For this it adds another opcode `Append $lhs` which appends the accumulator to the Array in $lhs, optionally spreading it.
2022-09-09 13:23:02 +00:00
class Append final : public Instruction {
public:
Append(Register lhs, bool is_spread)
: Instruction(Type::Append)
, m_lhs(lhs)
, m_is_spread(is_spread)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
private:
Register m_lhs;
bool m_is_spread = false;
};
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 21:06:26 +00:00
class IteratorToArray final : public Instruction {
public:
IteratorToArray()
: Instruction(Type::IteratorToArray)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 21:06:26 +00:00
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock 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-08 03:58:36 +00: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 09:22:46 +00: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-08 03:58:36 +00:00
: Instruction(Type::ConcatString)
, m_lhs(lhs)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock 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-08 03:58:36 +00:00
private:
Register m_lhs;
};
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 16:18:45 +00:00
enum class EnvironmentMode {
Lexical,
Var,
};
class CreateEnvironment final : public Instruction {
public:
explicit CreateEnvironment(EnvironmentMode mode)
: Instruction(Type::CreateEnvironment)
, m_mode(mode)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
private:
EnvironmentMode m_mode { EnvironmentMode::Lexical };
};
LibJS: Implement bytecode generation for WithStatement
2022-03-13 12:31:18 +00:00
class EnterObjectEnvironment final : public Instruction {
public:
explicit EnterObjectEnvironment()
: Instruction(Type::EnterObjectEnvironment)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
};
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 16:18:45 +00:00
class CreateVariable final : public Instruction {
public:
LibJS/Bytecode: Create global variables before setting them This allows them to be accessed before assignment, and also prevents throwing in strict mode as we are trying to set a non-existent variable.
2022-07-17 18:06:44 +00:00
explicit CreateVariable(IdentifierTableIndex identifier, EnvironmentMode mode, bool is_immutable, bool is_global = false)
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 16:18:45 +00:00
: Instruction(Type::CreateVariable)
, m_identifier(identifier)
, m_mode(mode)
, m_is_immutable(is_immutable)
LibJS/Bytecode: Create global variables before setting them This allows them to be accessed before assignment, and also prevents throwing in strict mode as we are trying to set a non-existent variable.
2022-07-17 18:06:44 +00:00
, m_is_global(is_global)
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 16:18:45 +00:00
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
private:
IdentifierTableIndex m_identifier;
EnvironmentMode m_mode;
LibJS/Bytecode: Create global variables before setting them This allows them to be accessed before assignment, and also prevents throwing in strict mode as we are trying to set a non-existent variable.
2022-07-17 18:06:44 +00:00
bool m_is_immutable : 4 { false };
bool m_is_global : 4 { false };
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 16:18:45 +00: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 16:26:32 +00:00
class SetVariable final : public Instruction {
public:
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 16:18:45 +00:00
enum class InitializationMode {
Initialize,
Set,
InitializeOrSet,
};
explicit SetVariable(IdentifierTableIndex identifier, InitializationMode initialization_mode = InitializationMode::Set, EnvironmentMode mode = EnvironmentMode::Lexical)
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 13:12:43 +00: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 09:22:46 +00:00
, m_identifier(identifier)
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 16:18:45 +00:00
, m_mode(mode)
, m_initialization_mode(initialization_mode)
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 16:26:32 +00:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock 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 16:26:32 +00:00
private:
LibJS: Add a separate "identifier table" to bytecode executables This is a specialized string table for storing identifiers only. Identifiers are always FlyStrings, which makes many common operations faster by allowing O(1) comparison.
2021-10-24 13:34:30 +00:00
IdentifierTableIndex m_identifier;
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 16:18:45 +00:00
EnvironmentMode m_mode;
InitializationMode m_initialization_mode { InitializationMode::Set };
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 16:26:32 +00:00
};
class GetVariable final : public Instruction {
public:
LibJS: Add a separate "identifier table" to bytecode executables This is a specialized string table for storing identifiers only. Identifiers are always FlyStrings, which makes many common operations faster by allowing O(1) comparison.
2021-10-24 13:34:30 +00:00
explicit GetVariable(IdentifierTableIndex 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 13:12:43 +00: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 09:22:46 +00: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 16:26:32 +00:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock 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 16:26:32 +00:00
private:
LibJS: Add a separate "identifier table" to bytecode executables This is a specialized string table for storing identifiers only. Identifiers are always FlyStrings, which makes many common operations faster by allowing O(1) comparison.
2021-10-24 13:34:30 +00:00
IdentifierTableIndex m_identifier;
LibJS: Add the "fast non-local access" optimization to the bytecode VM The GetVariable bytecode op now caches environment coordinates for fast cross-scope variable lookup.
2021-10-24 13:36:24 +00:00
Optional<EnvironmentCoordinate> mutable m_cached_environment_coordinate;
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 16:26:32 +00:00
};
LibJS/Bytecode: Implement the delete unary expression `delete` has to operate directly on Reference Records, so this introduces a new set of operations called DeleteByValue, DeleteVariable and DeleteById. They operate similarly to their Get counterparts, except they end in creating a (temporary) Reference and calling delete_ on it.
2022-03-27 18:50:09 +00:00
class DeleteVariable final : public Instruction {
public:
explicit DeleteVariable(IdentifierTableIndex identifier)
: Instruction(Type::DeleteVariable)
, m_identifier(identifier)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
private:
IdentifierTableIndex m_identifier;
};
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 19:03:53 +00:00
class GetById final : public Instruction {
public:
LibJS: Add a separate "identifier table" to bytecode executables This is a specialized string table for storing identifiers only. Identifiers are always FlyStrings, which makes many common operations faster by allowing O(1) comparison.
2021-10-24 13:34:30 +00:00
explicit GetById(IdentifierTableIndex 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 13:12:43 +00: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 09:22:46 +00:00
, m_property(property)
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 19:03:53 +00:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 19:03:53 +00:00
private:
LibJS: Add a separate "identifier table" to bytecode executables This is a specialized string table for storing identifiers only. Identifiers are always FlyStrings, which makes many common operations faster by allowing O(1) comparison.
2021-10-24 13:34:30 +00:00
IdentifierTableIndex m_property;
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 19:03:53 +00:00
};
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-30 20:29:58 +00:00
enum class PropertyKind {
Getter,
Setter,
KeyValue,
Spread,
ProtoSetter,
};
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 18:47:07 +00:00
class PutById final : public Instruction {
public:
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-30 20:29:58 +00:00
explicit PutById(Register base, IdentifierTableIndex property, PropertyKind kind = PropertyKind::KeyValue)
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 13:12:43 +00: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 09:22:46 +00:00
, m_property(property)
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-30 20:29:58 +00:00
, m_kind(kind)
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 18:47:07 +00:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock 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 18:47:07 +00:00
private:
Register m_base;
LibJS: Add a separate "identifier table" to bytecode executables This is a specialized string table for storing identifiers only. Identifiers are always FlyStrings, which makes many common operations faster by allowing O(1) comparison.
2021-10-24 13:34:30 +00:00
IdentifierTableIndex m_property;
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-30 20:29:58 +00:00
PropertyKind m_kind;
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 18:47:07 +00:00
};
LibJS/Bytecode: Implement the delete unary expression `delete` has to operate directly on Reference Records, so this introduces a new set of operations called DeleteByValue, DeleteVariable and DeleteById. They operate similarly to their Get counterparts, except they end in creating a (temporary) Reference and calling delete_ on it.
2022-03-27 18:50:09 +00:00
class DeleteById final : public Instruction {
public:
explicit DeleteById(IdentifierTableIndex property)
: Instruction(Type::DeleteById)
, m_property(property)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
private:
IdentifierTableIndex m_property;
};
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-10 22:35:25 +00:00
class GetByValue final : public Instruction {
public:
explicit GetByValue(Register base)
: Instruction(Type::GetByValue)
, m_base(base)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock 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-10 22:35:25 +00:00
private:
Register m_base;
};
class PutByValue final : public Instruction {
public:
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-30 20:29:58 +00:00
PutByValue(Register base, Register property, PropertyKind kind = PropertyKind::KeyValue)
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-10 22:35:25 +00:00
: Instruction(Type::PutByValue)
, m_base(base)
, m_property(property)
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-30 20:29:58 +00:00
, m_kind(kind)
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-10 22:35:25 +00:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock 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-10 22:35:25 +00:00
private:
Register m_base;
Register m_property;
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-30 20:29:58 +00:00
PropertyKind m_kind;
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-10 22:35:25 +00:00
};
LibJS/Bytecode: Implement the delete unary expression `delete` has to operate directly on Reference Records, so this introduces a new set of operations called DeleteByValue, DeleteVariable and DeleteById. They operate similarly to their Get counterparts, except they end in creating a (temporary) Reference and calling delete_ on it.
2022-03-27 18:50:09 +00:00
class DeleteByValue final : public Instruction {
public:
DeleteByValue(Register base)
: Instruction(Type::DeleteByValue)
, m_base(base)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
private:
Register m_base;
};
LibJS: Make JumpIf{True,False,Nullish} inherit from Jump This saves a few lines in LogicalExpression::generate_bytecode.
2021-06-08 09:28:27 +00: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 10:07:38 +00: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 02:19:58 +00:00
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 09:28:27 +00: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 02:19:58 +00:00
, 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 09:28:27 +00: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 02:19:58 +00:00
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 13:12:43 +00: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 02:19:58 +00:00
, 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 10:07:38 +00: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 02:19:58 +00:00
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 10:07:38 +00: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 02:19:58 +00:00
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 10:07:38 +00:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock const&);
auto& true_target() const { return m_true_target; }
auto& false_target() const { return m_false_target; }
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 02:19:58 +00:00
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 10:07:38 +00: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 02:19:58 +00:00
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 10:20:44 +00: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 02:19:58 +00:00
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 10:20:44 +00:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
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 10:20:44 +00: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 02:19:58 +00:00
class JumpNullish final : public Jump {
LibJS: Implement bytecode ops for logical expressions
2021-06-08 00:18:47 +00: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 02:19:58 +00:00
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 00:18:47 +00:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Implement bytecode ops for logical expressions
2021-06-08 00:18:47 +00:00
};
LibJS: Add JumpUndefined bytecode
2021-06-13 19:24:40 +00:00
class JumpUndefined final : public Jump {
public:
explicit JumpUndefined(Optional<Label> true_target = {}, Optional<Label> false_target = {})
: Jump(Type::JumpUndefined, move(true_target), move(false_target))
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
LibJS: Add JumpUndefined bytecode
2021-06-13 19:24:40 +00:00
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 13:12:43 +00: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 13:15:30 +00: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 21:01:49 +00:00
enum class CallType {
Call,
Construct,
};
LibJS: Switch to array-calls in the bytecode vm This will make it easier to implement spreading arguments.
2022-09-07 21:39:43 +00:00
Call(CallType type, Register callee, Register this_value)
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 13:12:43 +00: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 13:15:30 +00: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 21:01:49 +00:00
, m_type(type)
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 13:15:30 +00:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock 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 13:12:43 +00:00
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 13:15:30 +00: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 21:01:49 +00:00
CallType m_type;
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 13:15:30 +00:00
};
LibJS: Implement SuperCall for the Bytecode-VM
2022-08-30 16:03:02 +00:00
// NOTE: This instruction is variable-width depending on the number of arguments!
class SuperCall : public Instruction {
public:
LibJS: Switch to array-calls in the bytecode vm This will make it easier to implement spreading arguments.
2022-09-07 21:39:43 +00:00
explicit SuperCall(bool is_synthetic)
LibJS: Implement SuperCall for the Bytecode-VM
2022-08-30 16:03:02 +00:00
: Instruction(Type::SuperCall)
, m_is_synthetic(is_synthetic)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
private:
bool m_is_synthetic;
};
LibJS: NewClass bytecode instruction This adds a the NewClass bytecode instruction, enough of it is implemented for it to show it in the bytecode (js -d).
2021-06-30 18:42:13 +00:00
class NewClass final : public Instruction {
public:
explicit NewClass(ClassExpression const& class_expression)
: Instruction(Type::NewClass)
, m_class_expression(class_expression)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
LibJS: NewClass bytecode instruction This adds a the NewClass bytecode instruction, enough of it is implemented for it to show it in the bytecode (js -d).
2021-06-30 18:42:13 +00:00
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
private:
ClassExpression const& m_class_expression;
};
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-09 22:49:23 +00: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 13:14:09 +00: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-09 22:49:23 +00: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 13:14:09 +00:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock 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 13:14:09 +00: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-09 22:49:23 +00: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 13:14:09 +00: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 13:53:36 +00: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 02:19:58 +00:00
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-08 03:58:36 +00: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 13:12:43 +00: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 13:53:36 +00:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock 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 13:53:36 +00: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 09:40:38 +00:00
class Increment final : public Instruction {
public:
Increment()
: Instruction(Type::Increment)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock 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 09:40:38 +00:00
};
class Decrement final : public Instruction {
public:
Decrement()
: Instruction(Type::Decrement)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock 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 09:40:38 +00:00
};
LibJS: Generate bytecode for throw statements
2021-06-09 16:18:56 +00:00
class Throw final : public Instruction {
public:
constexpr static bool IsTerminator = true;
Throw()
: Instruction(Type::Throw)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
LibJS: Generate bytecode for throw statements
2021-06-09 16:18:56 +00: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 13:04:38 +00: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 16:09:40 +00:00
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 13:04:38 +00: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 16:09:40 +00:00
, 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 09:22:46 +00: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 13:04:38 +00:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock const&);
auto& entry_point() const { return m_entry_point; }
auto& handler_target() const { return m_handler_target; }
auto& finalizer_target() const { return m_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 13:04:38 +00: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 16:09:40 +00:00
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 13:04:38 +00:00
Optional<Label> m_handler_target;
Optional<Label> m_finalizer_target;
};
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 16:18:45 +00:00
class LeaveEnvironment final : public Instruction {
public:
LeaveEnvironment(EnvironmentMode mode)
: Instruction(Type::LeaveEnvironment)
, m_mode(mode)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
private:
EnvironmentMode m_mode { EnvironmentMode::Lexical };
};
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 13:04:38 +00:00
class LeaveUnwindContext final : public Instruction {
public:
LeaveUnwindContext()
: Instruction(Type::LeaveUnwindContext)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock 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 13:04:38 +00:00
};
LibJS: Fix codegen for nodes after try statements without 'finally' Previously we were just dropping them on the ground :P
2021-11-10 18:52:26 +00:00
class FinishUnwind final : public Instruction {
public:
FinishUnwind(Label next)
: Instruction(Type::FinishUnwind)
, m_next_target(move(next))
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
LibJS: Fix codegen for nodes after try statements without 'finally' Previously we were just dropping them on the ground :P
2021-11-10 18:52:26 +00:00
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&);
private:
Label m_next_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 13:04:38 +00: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 09:22:46 +00: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 13:04:38 +00:00
: Instruction(Type::ContinuePendingUnwind)
, m_resume_target(resume_target)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock const&);
auto& resume_target() const { return m_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 13:04:38 +00: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 20:12:21 +00:00
LibJS: Implement generator functions (only in bytecode mode)
2021-06-10 21:08:30 +00:00
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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock const&);
auto& continuation() const { return m_continuation_label; }
LibJS: Implement generator functions (only in bytecode mode)
2021-06-10 21:08:30 +00:00
private:
Optional<Label> m_continuation_label;
};
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 10:24:46 +00:00
class PushDeclarativeEnvironment final : public Instruction {
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 20:12:21 +00:00
public:
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 10:24:46 +00:00
explicit PushDeclarativeEnvironment(HashMap<u32, Variable> variables)
: Instruction(Type::PushDeclarativeEnvironment)
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 20:12:21 +00:00
, m_variables(move(variables))
{
}
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 20:40:48 +00:00
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
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 13:38:12 +00:00
String to_string_impl(Bytecode::Executable const&) const;
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
void replace_references_impl(BasicBlock const&, BasicBlock 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 20:12:21 +00:00
LibJS: Implement generator functions (only in bytecode mode)
2021-06-10 21:08:30 +00:00
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 20:12:21 +00: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 07:37:35 +00:00
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 20:40:48 +00:00
class GetIterator final : public Instruction {
public:
GetIterator()
: Instruction(Type::GetIterator)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 20:40:48 +00:00
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
};
LibJS: Implement bytecode generation for For-In/Of statements This also implements the rather interesting behaviour that #12772 relies on, so this fixes that bug in BC mode (the AST interp remains affected).
2022-03-18 16:48:19 +00:00
class GetObjectPropertyIterator final : public Instruction {
public:
GetObjectPropertyIterator()
: Instruction(Type::GetObjectPropertyIterator)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
};
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 20:40:48 +00:00
class IteratorNext final : public Instruction {
public:
IteratorNext()
: Instruction(Type::IteratorNext)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 20:40:48 +00:00
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
};
class IteratorResultDone final : public Instruction {
public:
IteratorResultDone()
: Instruction(Type::IteratorResultDone)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 20:40:48 +00:00
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
};
class IteratorResultValue final : public Instruction {
public:
IteratorResultValue()
: Instruction(Type::IteratorResultValue)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 20:40:48 +00:00
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
};
LibJS: Implement 'this' in the bytecode VM ThisExpression now emits a "ResolveThisBinding" bytecode op, which simply loads the VM's current 'this' binding into the accumulator.
2021-10-24 12:43:00 +00:00
class ResolveThisBinding final : public Instruction {
public:
explicit ResolveThisBinding()
: Instruction(Type::ResolveThisBinding)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
LibJS: Implement 'this' in the bytecode VM ThisExpression now emits a "ResolveThisBinding" bytecode op, which simply loads the VM's current 'this' binding into the accumulator.
2021-10-24 12:43:00 +00:00
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
};
LibJS/Bytecode: Add support for new.target
2022-03-19 19:40:21 +00:00
class GetNewTarget final : public Instruction {
public:
explicit GetNewTarget()
: Instruction(Type::GetNewTarget)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
};
LibJS/Bytecode: Make typeof return "undefined" on unresolvable IDs Previously it would throw instead of returning "undefined" for `typeof Identifier` if Identifier does not exist.
2022-06-11 22:12:22 +00:00
class TypeofVariable final : public Instruction {
public:
explicit TypeofVariable(IdentifierTableIndex identifier)
: Instruction(Type::TypeofVariable)
, m_identifier(identifier)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
String to_string_impl(Bytecode::Executable const&) const;
void replace_references_impl(BasicBlock const&, BasicBlock const&) { }
private:
IdentifierTableIndex m_identifier;
};
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 08:46:30 +00: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 07:19:34 +00:00
namespace JS::Bytecode {
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 13:36:45 +00:00
ALWAYS_INLINE ThrowCompletionOr<void> Instruction::execute(Bytecode::Interpreter& interpreter) const
LibJS: Move Bytecode::Instruction::execute() to the Op.h header ..and make sure it always gets inlined in the interpreter loop.
2021-06-09 07:19:34 +00:00
{
#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 13:38:12 +00:00
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 07:19:34 +00:00
switch (type()) {
ENUMERATE_BYTECODE_OPS(__BYTECODE_OP)
default:
VERIFY_NOT_REACHED();
}
#undef __BYTECODE_OP
}
LibJS: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
ALWAYS_INLINE void Instruction::replace_references(BasicBlock const& from, BasicBlock const& to)
{
#define __BYTECODE_OP(op) \
case Instruction::Type::op: \
return static_cast<Bytecode::Op::op&>(*this).replace_references_impl(from, to);
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 07:23:38 +00:00
ALWAYS_INLINE size_t Instruction::length() const
{
LibJS: Implement SuperCall for the Bytecode-VM
2022-08-30 16:03:02 +00:00
if (type() == Type::NewArray)
LibJS: Align Instructions as void* and roundup variably sized ones sizes Both is indeed needed, the standard alignment would have been 4, but some Instructions, like Jumps need an alignment of 8 Fixes #12127.
2022-09-09 14:47:42 +00:00
return round_up_to_power_of_two(static_cast<Op::NewArray const&>(*this).length_impl(), alignof(void*));
LibJS: Implement SuperCall for the Bytecode-VM
2022-08-30 16:03:02 +00:00
if (type() == Type::CopyObjectExcludingProperties)
LibJS: Align Instructions as void* and roundup variably sized ones sizes Both is indeed needed, the standard alignment would have been 4, but some Instructions, like Jumps need an alignment of 8 Fixes #12127.
2022-09-09 14:47:42 +00:00
return round_up_to_power_of_two(static_cast<Op::CopyObjectExcludingProperties const&>(*this).length_impl(), alignof(void*));
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 07:23:38 +00: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: Add a basic pass manager and add some basic passes This commit adds a bunch of passes, the most interesting of which is a pass that merges blocks together, and a pass that places blocks that flow into each other next to each other, and a very simply pass that removes duplicate basic blocks. Note that this does not remove the jump at the end of each block in that pass to avoid scope creep in the passes.
2021-06-13 16:10:20 +00:00
ALWAYS_INLINE bool Instruction::is_terminator() const
{
#define __BYTECODE_OP(op) \
case Type::op: \
return Op::op::IsTerminator;
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 07:19:34 +00:00
}
Reference in a new issue Copy permalink