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

1456 lines
45 KiB
C
Raw Normal View History

LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
/*
LibJS/Bytecode: Add codegen for ImportCall Also moved most of the AST ImportCall::execute() into a helper so we can share the code.
2023-06-24 15:22:16 +02:00
* Copyright (c) 2021-2023, Andreas Kling <kling@serenityos.org>
LibJS: Add bytecode generation for BinaryOp::In
2021-06-07 21:13:37 +01:00
* Copyright (c) 2021, Linus Groh <linusg@serenityos.org>
LibJS: Generate bytecode for throw statements
2021-06-09 18:18:56 +02:00
* Copyright (c) 2021, Gunnar Beutner <gbeutner@serenityos.org>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibJS: 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 16:47:42 +02:00
#include <AK/StdLibExtras.h>
LibJS: Implement bytecode generation for BigInts
2021-06-08 07:59:25 +02: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 15:34:30 +02: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 10:46:30 +02:00
#include <LibJS/Bytecode/Instruction.h>
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
#include <LibJS/Bytecode/Label.h>
LibJS/Bytecode: Don't reparse regular expressions on instantiation The RegExpLiteral AST node already has the parsed regex::Parser::Result so let's plumb that over to the bytecode executable instead of reparsing the regex every time NewRegExp is executed. ~12% speed-up on language/literals/regexp/S7.8.5_A2.1_T2.js in test262.
2023-07-13 10:49:07 +02:00
#include <LibJS/Bytecode/RegexTable.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
#include <LibJS/Bytecode/Register.h>
LibJS: Store strings in a string table Instead of using Strings in the bytecode ops this adds a global string table to the Executable struct which individual operations can refer to using indices. This brings bytecode ops one step closer to being pointer free.
2021-06-09 10:02:01 +02:00
#include <LibJS/Bytecode/StringTable.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
#include <LibJS/Heap/Cell.h>
LibJS: 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 12:24:46 +02:00
#include <LibJS/Runtime/Environment.h>
LibJS+LibWeb: Move IteratorOperations.h AOs to Iterator.h Rather than splitting the Iterator type and its AOs into two files, let's combine them into one file to match every other JS runtime object that we have.
2023-07-19 06:54:48 -04:00
#include <LibJS/Runtime/Iterator.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
#include <LibJS/Runtime/Value.h>
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 00:48:23 -08: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 10:46:30 +02:00
LibJS/Bytecode: Add codegen for "named evaluation if anonymous function" This gives anonymous functions the name from the LHS they are being assigned to. 171 new passes on test262. :^)
2023-06-23 14:27:42 +02:00
namespace JS {
class FunctionExpression;
}
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
namespace JS::Bytecode::Op {
class Load final : public Instruction {
public:
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
explicit Load(Register src)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::Load, sizeof(*this))
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
, m_src(src)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
LibJS: Inline bytecode ops for direct local/register access These can do a lot less stuff if we put them directly in the interpreter loop and allow them to access the locals/registers arrays directly.
2023-09-27 10:31:07 +02:00
Register src() const { return m_src; }
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
private:
Register m_src;
};
class LoadImmediate final : public Instruction {
public:
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
explicit LoadImmediate(Value value)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::LoadImmediate, sizeof(*this))
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
, m_value(value)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
LibJS: Inline bytecode ops for direct local/register access These can do a lot less stuff if we put them directly in the interpreter loop and allow them to access the locals/registers arrays directly.
2023-09-27 10:31:07 +02:00
Value value() const { return m_value; }
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
private:
Value m_value;
};
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
class Store final : public Instruction {
LibJS: Make sure that if expressions yield the correct value When evaluated as an expression "if (true) { 3 } else { 5 }" should yield 3. This updates the bytecode interpreter to make it so.
2021-06-07 22:05:09 +02:00
public:
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
explicit Store(Register dst)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::Store, sizeof(*this))
LibJS: Make sure that if expressions yield the correct value When evaluated as an expression "if (true) { 3 } else { 5 }" should yield 3. This updates the bytecode interpreter to make it so.
2021-06-07 22:05:09 +02:00
, m_dst(dst)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Make sure that if expressions yield the correct value When evaluated as an expression "if (true) { 3 } else { 5 }" should yield 3. This updates the bytecode interpreter to make it so.
2021-06-07 22:05:09 +02:00
LibJS: Expose some internals of Instructions These will be needed in the future to allow optimization passes to check against these
2022-10-22 20:21:08 +02:00
Register dst() const { return m_dst; }
LibJS: Make sure that if expressions yield the correct value When evaluated as an expression "if (true) { 3 } else { 5 }" should yield 3. This updates the bytecode interpreter to make it so.
2021-06-07 22:05:09 +02:00
private:
Register m_dst;
};
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
#define JS_ENUMERATE_COMMON_BINARY_OPS(O) \
O(Add, add) \
O(Sub, sub) \
O(Mul, mul) \
O(Div, div) \
O(Exp, exp) \
O(Mod, mod) \
O(In, in) \
O(InstanceOf, instance_of) \
O(GreaterThan, greater_than) \
O(GreaterThanEquals, greater_than_equals) \
O(LessThan, less_than) \
O(LessThanEquals, less_than_equals) \
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-24 00:06:10 +02: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 23:08:35 +02: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)
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
#define JS_DECLARE_COMMON_BINARY_OP(OpTitleCase, op_snake_case) \
class OpTitleCase final : public Instruction { \
public: \
explicit OpTitleCase(Register lhs_reg) \
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::OpTitleCase, sizeof(*this)) \
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
, m_lhs_reg(lhs_reg) \
{ \
} \
\
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const; \
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const; \
\
LibJS: Work-in-progress JIT compiler :^)
2023-10-14 14:37:48 +02:00
Register lhs() const { return m_lhs_reg; } \
\
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
private: \
Register m_lhs_reg; \
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
};
JS_ENUMERATE_COMMON_BINARY_OPS(JS_DECLARE_COMMON_BINARY_OP)
#undef JS_DECLARE_COMMON_BINARY_OP
#define JS_ENUMERATE_COMMON_UNARY_OPS(O) \
O(BitwiseNot, bitwise_not) \
O(Not, not_) \
O(UnaryPlus, unary_plus) \
O(UnaryMinus, unary_minus) \
O(Typeof, typeof_)
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
#define JS_DECLARE_COMMON_UNARY_OP(OpTitleCase, op_snake_case) \
class OpTitleCase final : public Instruction { \
public: \
OpTitleCase() \
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::OpTitleCase, sizeof(*this)) \
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
{ \
} \
\
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const; \
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const; \
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
};
JS_ENUMERATE_COMMON_UNARY_OPS(JS_DECLARE_COMMON_UNARY_OP)
#undef JS_DECLARE_COMMON_UNARY_OP
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
class NewString final : public Instruction {
public:
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
explicit NewString(StringTableIndex string)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::NewString, sizeof(*this))
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
, m_string(string)
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
LibJS/JIT: Support the NewString bytecode op This necessitated making the JIT::Compiler aware of the current Bytecode::Executable, since that's where all the string literals are held, but that seems like a good thing.
2023-10-18 12:55:00 +02:00
StringTableIndex index() const { return m_string; }
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
private:
LibJS: Store strings in a string table Instead of using Strings in the bytecode ops this adds a global string table to the Executable struct which individual operations can refer to using indices. This brings bytecode ops one step closer to being pointer free.
2021-06-09 10:02:01 +02:00
StringTableIndex m_string;
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
};
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 20:30:23 +02:00
class NewObject final : public Instruction {
public:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
NewObject()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::NewObject, sizeof(*this))
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 20:30:23 +02:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 20:30:23 +02:00
};
LibJS: Add bytecode support for regexp literals
2021-06-19 17:17:40 -07:00
class NewRegExp final : public Instruction {
public:
LibJS/Bytecode: Don't reparse regular expressions on instantiation The RegExpLiteral AST node already has the parsed regex::Parser::Result so let's plumb that over to the bytecode executable instead of reparsing the regex every time NewRegExp is executed. ~12% speed-up on language/literals/regexp/S7.8.5_A2.1_T2.js in test262.
2023-07-13 10:49:07 +02:00
NewRegExp(StringTableIndex source_index, StringTableIndex flags_index, RegexTableIndex regex_index)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::NewRegExp, sizeof(*this))
LibJS: Add bytecode support for regexp literals
2021-06-19 17:17:40 -07:00
, m_source_index(source_index)
, m_flags_index(flags_index)
LibJS/Bytecode: Don't reparse regular expressions on instantiation The RegExpLiteral AST node already has the parsed regex::Parser::Result so let's plumb that over to the bytecode executable instead of reparsing the regex every time NewRegExp is executed. ~12% speed-up on language/literals/regexp/S7.8.5_A2.1_T2.js in test262.
2023-07-13 10:49:07 +02:00
, m_regex_index(regex_index)
LibJS: Add bytecode support for regexp literals
2021-06-19 17:17:40 -07:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Add bytecode support for regexp literals
2021-06-19 17:17:40 -07:00
private:
StringTableIndex m_source_index;
StringTableIndex m_flags_index;
LibJS/Bytecode: Don't reparse regular expressions on instantiation The RegExpLiteral AST node already has the parsed regex::Parser::Result so let's plumb that over to the bytecode executable instead of reparsing the regex every time NewRegExp is executed. ~12% speed-up on language/literals/regexp/S7.8.5_A2.1_T2.js in test262.
2023-07-13 10:49:07 +02:00
RegexTableIndex m_regex_index;
LibJS: Add bytecode support for regexp literals
2021-06-19 17:17:40 -07:00
};
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
#define JS_ENUMERATE_NEW_BUILTIN_ERROR_OPS(O) \
O(TypeError)
#define JS_DECLARE_NEW_BUILTIN_ERROR_OP(ErrorName) \
class New##ErrorName final : public Instruction { \
public: \
explicit New##ErrorName(StringTableIndex error_string) \
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::New##ErrorName, sizeof(*this)) \
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
, m_error_string(error_string) \
{ \
} \
\
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const; \
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const; \
\
private: \
StringTableIndex m_error_string; \
};
JS_ENUMERATE_NEW_BUILTIN_ERROR_OPS(JS_DECLARE_NEW_BUILTIN_ERROR_OP)
#undef JS_DECLARE_NEW_BUILTIN_ERROR_OP
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07: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)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::CopyObjectExcludingProperties, length_impl(excluded_names.size()))
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
, 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 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
size_t length_impl(size_t excluded_names_count) const
{
return round_up_to_power_of_two(alignof(void*), sizeof(*this) + sizeof(Register) * excluded_names_count);
}
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
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 07:59:25 +02:00
class NewBigInt final : public Instruction {
public:
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
explicit NewBigInt(Crypto::SignedBigInteger bigint)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::NewBigInt, sizeof(*this))
LibJS: Implement bytecode generation for BigInts
2021-06-08 07:59:25 +02:00
, m_bigint(move(bigint))
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Implement bytecode generation for BigInts
2021-06-08 07:59:25 +02:00
private:
Crypto::SignedBigInteger m_bigint;
};
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
// NOTE: This instruction is variable-width depending on the number of elements!
class NewArray final : public Instruction {
public:
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
NewArray()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::NewArray, length_impl(0))
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
, 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: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::NewArray, length_impl(elements_range[1].index() - elements_range[0].index() + 1))
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 23:06:52 +02: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 23:06:52 +02:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
size_t length_impl(size_t element_count) 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 20:40:20 +04:30
{
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
return round_up_to_power_of_two(alignof(void*), sizeof(*this) + sizeof(Register) * (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 20:40:20 +04:30
}
LibJS: Add missing length() method for NewArray
2021-06-12 05:49:09 +02:00
LibJS: Expose some internals of Instructions These will be needed in the future to allow optimization passes to check against these
2022-10-22 20:21:08 +02:00
Register start() const
{
VERIFY(m_element_count);
return m_elements[0];
}
Register end() const
{
VERIFY(m_element_count);
return m_elements[1];
}
size_t element_count() const { return m_element_count; }
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
private:
size_t m_element_count { 0 };
Register m_elements[];
};
LibJS: 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 15:23:02 +02:00
class Append final : public Instruction {
public:
Append(Register lhs, bool is_spread)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::Append, sizeof(*this))
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 15:23:02 +02:00
, m_lhs(lhs)
, m_is_spread(is_spread)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Add a way to replace references to registers in Bytecode
2022-10-22 20:19:16 +02:00
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 15:23:02 +02:00
private:
Register m_lhs;
bool m_is_spread = false;
};
LibJS/Bytecode: Add codegen for ImportCall Also moved most of the AST ImportCall::execute() into a helper so we can share the code.
2023-06-24 15:22:16 +02:00
class ImportCall final : public Instruction {
public:
ImportCall(Register specifier, Register options)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::ImportCall, sizeof(*this))
LibJS/Bytecode: Add codegen for ImportCall Also moved most of the AST ImportCall::execute() into a helper so we can share the code.
2023-06-24 15:22:16 +02:00
, m_specifier(specifier)
, m_options(options)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
private:
Register m_specifier;
Register m_options;
};
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
class IteratorToArray final : public Instruction {
public:
IteratorToArray()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::IteratorToArray, sizeof(*this))
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
};
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
class ConcatString final : public Instruction {
public:
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
explicit ConcatString(Register lhs)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::ConcatString, sizeof(*this))
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
, m_lhs(lhs)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
private:
Register m_lhs;
};
LibJS: 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 19:48:45 +03:30
enum class EnvironmentMode {
Lexical,
Var,
};
LibJS/Bytecode: Simplify creating/leaving lexical environment Since we no longer need to create or leave var environments directly in bytecode, we can streamline the two instructions by making them always operate on the lexical environment.
2023-06-16 16:43:24 +02:00
class CreateLexicalEnvironment final : public Instruction {
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 19:48:45 +03:30
public:
LibJS/Bytecode: Simplify creating/leaving lexical environment Since we no longer need to create or leave var environments directly in bytecode, we can streamline the two instructions by making them always operate on the lexical environment.
2023-06-16 16:43:24 +02:00
explicit CreateLexicalEnvironment()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::CreateLexicalEnvironment, sizeof(*this))
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 19:48:45 +03:30
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) 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 19:48:45 +03:30
};
LibJS: Implement bytecode generation for WithStatement
2022-03-13 16:01:18 +03:30
class EnterObjectEnvironment final : public Instruction {
public:
explicit EnterObjectEnvironment()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::EnterObjectEnvironment, sizeof(*this))
LibJS: Implement bytecode generation for WithStatement
2022-03-13 16:01:18 +03:30
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Implement bytecode generation for WithStatement
2022-03-13 16:01:18 +03:30
};
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 19:48:45 +03:30
class CreateVariable final : public Instruction {
public:
LibJS: Create const variables in ForIn/OfBodyEvaluation in strict mode Our implementation of environment.CreateImmutableBinding(name, true) in this AO was not correctly initializing const variables in strict mode. This would mean that constant declarations in for loop bodies would not throw if they were modified. To fix this, add a new parameter to CreateVariable to set strict mode. Also remove the vm.is_strict mode check here, as it doesn't look like anywhere in the spec will change strict mode depending on whether the script itself is running in script mode or not. This fixes two of our test-js tests, no change to test262.
2023-09-17 21:53:48 +12:00
explicit CreateVariable(IdentifierTableIndex identifier, EnvironmentMode mode, bool is_immutable, bool is_global = false, bool is_strict = false)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::CreateVariable, sizeof(*this))
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 19:48:45 +03:30
, 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 19:06:44 +01:00
, m_is_global(is_global)
LibJS: Create const variables in ForIn/OfBodyEvaluation in strict mode Our implementation of environment.CreateImmutableBinding(name, true) in this AO was not correctly initializing const variables in strict mode. This would mean that constant declarations in for loop bodies would not throw if they were modified. To fix this, add a new parameter to CreateVariable to set strict mode. Also remove the vm.is_strict mode check here, as it doesn't look like anywhere in the spec will change strict mode depending on whether the script itself is running in script mode or not. This fixes two of our test-js tests, no change to test262.
2023-09-17 21:53:48 +12:00
, m_is_strict(is_strict)
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 19:48:45 +03:30
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) 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 19:48:45 +03:30
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 19:06:44 +01:00
bool m_is_immutable : 4 { false };
bool m_is_global : 4 { false };
LibJS: Create const variables in ForIn/OfBodyEvaluation in strict mode Our implementation of environment.CreateImmutableBinding(name, true) in this AO was not correctly initializing const variables in strict mode. This would mean that constant declarations in for loop bodies would not throw if they were modified. To fix this, add a new parameter to CreateVariable to set strict mode. Also remove the vm.is_strict mode check here, as it doesn't look like anywhere in the spec will change strict mode depending on whether the script itself is running in script mode or not. This fixes two of our test-js tests, no change to test262.
2023-09-17 21:53:48 +12:00
bool m_is_strict { 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 19:48:45 +03:30
};
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
class SetVariable final : public Instruction {
public:
LibJS: 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 19:48:45 +03:30
enum class InitializationMode {
Initialize,
Set,
};
explicit SetVariable(IdentifierTableIndex identifier, InitializationMode initialization_mode = InitializationMode::Set, EnvironmentMode mode = EnvironmentMode::Lexical)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::SetVariable, sizeof(*this))
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
, m_identifier(identifier)
LibJS: 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 19:48:45 +03:30
, 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 18:26:32 +02:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
LibJS: Expose some internals of Instructions These will be needed in the future to allow optimization passes to check against these
2022-10-22 20:21:08 +02:00
IdentifierTableIndex identifier() const { return m_identifier; }
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
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 15:34:30 +02: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 19:48:45 +03:30
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 18:26:32 +02:00
};
LibJS: Update bytecode generator to use local variables - Update ECMAScriptFunctionObject::function_declaration_instantiation to initialize local variables - Introduce GetLocal, SetLocal, TypeofLocal that will be used to operate on local variables. - Update bytecode generator to emit instructions for local variables
2023-07-05 02:17:10 +02:00
class SetLocal final : public Instruction {
public:
explicit SetLocal(size_t index)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::SetLocal, sizeof(*this))
LibJS: Update bytecode generator to use local variables - Update ECMAScriptFunctionObject::function_declaration_instantiation to initialize local variables - Introduce GetLocal, SetLocal, TypeofLocal that will be used to operate on local variables. - Update bytecode generator to emit instructions for local variables
2023-07-05 02:17:10 +02:00
, m_index(index)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
size_t index() const { return m_index; }
private:
size_t m_index;
};
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 14:33:58 +02:00
class GetCalleeAndThisFromEnvironment final : public Instruction {
public:
LibJS/Bytecode: Move environment coordinate caches to Executable Moving them out of the respective instructions allows the bytecode stream to be immutable.
2023-10-26 10:39:40 +02:00
explicit GetCalleeAndThisFromEnvironment(IdentifierTableIndex identifier, Register callee_reg, Register this_reg, u32 cache_index)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::GetCalleeAndThisFromEnvironment, sizeof(*this))
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 14:33:58 +02:00
, m_identifier(identifier)
, m_callee_reg(callee_reg)
, m_this_reg(this_reg)
LibJS/Bytecode: Move environment coordinate caches to Executable Moving them out of the respective instructions allows the bytecode stream to be immutable.
2023-10-26 10:39:40 +02:00
, m_cache_index(cache_index)
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 14:33:58 +02:00
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
IdentifierTableIndex identifier() const { return m_identifier; }
LibJS/Bytecode: Move environment coordinate caches to Executable Moving them out of the respective instructions allows the bytecode stream to be immutable.
2023-10-26 10:39:40 +02:00
u32 cache_index() const { return m_cache_index; }
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 14:33:58 +02:00
private:
IdentifierTableIndex m_identifier;
Register m_callee_reg;
Register m_this_reg;
LibJS/Bytecode: Move environment coordinate caches to Executable Moving them out of the respective instructions allows the bytecode stream to be immutable.
2023-10-26 10:39:40 +02:00
u32 m_cache_index { 0 };
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 14:33:58 +02:00
};
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
class GetVariable final : public Instruction {
public:
LibJS/Bytecode: Move environment coordinate caches to Executable Moving them out of the respective instructions allows the bytecode stream to be immutable.
2023-10-26 10:39:40 +02:00
explicit GetVariable(IdentifierTableIndex identifier, u32 cache_index)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::GetVariable, sizeof(*this))
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
, m_identifier(identifier)
LibJS/Bytecode: Move environment coordinate caches to Executable Moving them out of the respective instructions allows the bytecode stream to be immutable.
2023-10-26 10:39:40 +02:00
, m_cache_index(cache_index)
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
LibJS: Expose some internals of Instructions These will be needed in the future to allow optimization passes to check against these
2022-10-22 20:21:08 +02:00
IdentifierTableIndex identifier() const { return m_identifier; }
LibJS/Bytecode: Move environment coordinate caches to Executable Moving them out of the respective instructions allows the bytecode stream to be immutable.
2023-10-26 10:39:40 +02:00
u32 cache_index() const { return m_cache_index; }
LibJS: Expose some internals of Instructions These will be needed in the future to allow optimization passes to check against these
2022-10-22 20:21:08 +02:00
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
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 15:34:30 +02:00
IdentifierTableIndex m_identifier;
LibJS/Bytecode: Move environment coordinate caches to Executable Moving them out of the respective instructions allows the bytecode stream to be immutable.
2023-10-26 10:39:40 +02:00
u32 m_cache_index { 0 };
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
};
LibJS: Add optimized GetGlobal instruction to access global variables Using a special instruction to access global variables allows skipping the environment chain traversal for them and going directly to the module/global environment. Currently, this instruction only caches the offset for bindings that belong to the global object environment. However, there is also an opportunity to cache the offset in the global declarative record. This change results in a 57% increase in speed for imaging-gaussian-blur.js in Kraken.
2023-07-12 04:06:59 +02:00
class GetGlobal final : public Instruction {
public:
explicit GetGlobal(IdentifierTableIndex identifier, u32 cache_index)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::GetGlobal, sizeof(*this))
LibJS: Add optimized GetGlobal instruction to access global variables Using a special instruction to access global variables allows skipping the environment chain traversal for them and going directly to the module/global environment. Currently, this instruction only caches the offset for bindings that belong to the global object environment. However, there is also an opportunity to cache the offset in the global declarative record. This change results in a 57% increase in speed for imaging-gaussian-blur.js in Kraken.
2023-07-12 04:06:59 +02:00
, m_identifier(identifier)
, m_cache_index(cache_index)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS/JIT: Compile the GetGlobal bytecode instruction
2023-10-20 12:56:12 +02:00
IdentifierTableIndex identifier() const { return m_identifier; }
u32 cache_index() const { return m_cache_index; }
LibJS: Add optimized GetGlobal instruction to access global variables Using a special instruction to access global variables allows skipping the environment chain traversal for them and going directly to the module/global environment. Currently, this instruction only caches the offset for bindings that belong to the global object environment. However, there is also an opportunity to cache the offset in the global declarative record. This change results in a 57% increase in speed for imaging-gaussian-blur.js in Kraken.
2023-07-12 04:06:59 +02:00
private:
IdentifierTableIndex m_identifier;
u32 m_cache_index { 0 };
};
LibJS: Update bytecode generator to use local variables - Update ECMAScriptFunctionObject::function_declaration_instantiation to initialize local variables - Introduce GetLocal, SetLocal, TypeofLocal that will be used to operate on local variables. - Update bytecode generator to emit instructions for local variables
2023-07-05 02:17:10 +02:00
class GetLocal final : public Instruction {
public:
explicit GetLocal(size_t index)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::GetLocal, sizeof(*this))
LibJS: Update bytecode generator to use local variables - Update ECMAScriptFunctionObject::function_declaration_instantiation to initialize local variables - Introduce GetLocal, SetLocal, TypeofLocal that will be used to operate on local variables. - Update bytecode generator to emit instructions for local variables
2023-07-05 02:17:10 +02:00
, m_index(index)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
size_t index() const { return m_index; }
private:
size_t m_index;
};
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 19:50:09 +01:00
class DeleteVariable final : public Instruction {
public:
explicit DeleteVariable(IdentifierTableIndex identifier)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::DeleteVariable, sizeof(*this))
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 19:50:09 +01:00
, m_identifier(identifier)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
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 19:50:09 +01:00
LibJS: Expose some internals of Instructions These will be needed in the future to allow optimization passes to check against these
2022-10-22 20:21:08 +02:00
IdentifierTableIndex identifier() const { return m_identifier; }
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 19:50:09 +01:00
private:
IdentifierTableIndex m_identifier;
};
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 21:03:53 +02:00
class GetById final : public Instruction {
public:
LibJS/Bytecode: Cache object own property accesses The instructions GetById and GetByIdWithThis now remember the last-seen Shape, and if we see the same object again, we reuse the property offset from last time without doing a new lookup. This allows us to use Object::get_direct(), bypassing the entire lookup machinery and saving lots of time. ~23% speed-up on Kraken/ai-astar.js :^)
2023-07-08 17:43:26 +02:00
GetById(IdentifierTableIndex property, u32 cache_index)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::GetById, sizeof(*this))
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
, m_property(property)
LibJS/Bytecode: Cache object own property accesses The instructions GetById and GetByIdWithThis now remember the last-seen Shape, and if we see the same object again, we reuse the property offset from last time without doing a new lookup. This allows us to use Object::get_direct(), bypassing the entire lookup machinery and saving lots of time. ~23% speed-up on Kraken/ai-astar.js :^)
2023-07-08 17:43:26 +02:00
, m_cache_index(cache_index)
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 21:03:53 +02:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 21:03:53 +02:00
LibJS/JIT: Support the GetById bytecode op We can now do basic property (get) access in jitted code! :^)
2023-10-18 13:27:56 +02:00
IdentifierTableIndex property() const { return m_property; }
u32 cache_index() const { return m_cache_index; }
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 21:03:53 +02:00
private:
LibJS: 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 15:34:30 +02:00
IdentifierTableIndex m_property;
LibJS/Bytecode: Cache object own property accesses The instructions GetById and GetByIdWithThis now remember the last-seen Shape, and if we see the same object again, we reuse the property offset from last time without doing a new lookup. This allows us to use Object::get_direct(), bypassing the entire lookup machinery and saving lots of time. ~23% speed-up on Kraken/ai-astar.js :^)
2023-07-08 17:43:26 +02:00
u32 m_cache_index { 0 };
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 21:03:53 +02:00
};
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
class GetByIdWithThis final : public Instruction {
public:
LibJS/Bytecode: Cache object own property accesses The instructions GetById and GetByIdWithThis now remember the last-seen Shape, and if we see the same object again, we reuse the property offset from last time without doing a new lookup. This allows us to use Object::get_direct(), bypassing the entire lookup machinery and saving lots of time. ~23% speed-up on Kraken/ai-astar.js :^)
2023-07-08 17:43:26 +02:00
GetByIdWithThis(IdentifierTableIndex property, Register this_value, u32 cache_index)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::GetByIdWithThis, sizeof(*this))
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
, m_property(property)
, m_this_value(this_value)
LibJS/Bytecode: Cache object own property accesses The instructions GetById and GetByIdWithThis now remember the last-seen Shape, and if we see the same object again, we reuse the property offset from last time without doing a new lookup. This allows us to use Object::get_direct(), bypassing the entire lookup machinery and saving lots of time. ~23% speed-up on Kraken/ai-astar.js :^)
2023-07-08 17:43:26 +02:00
, m_cache_index(cache_index)
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
private:
IdentifierTableIndex m_property;
Register m_this_value;
LibJS/Bytecode: Cache object own property accesses The instructions GetById and GetByIdWithThis now remember the last-seen Shape, and if we see the same object again, we reuse the property offset from last time without doing a new lookup. This allows us to use Object::get_direct(), bypassing the entire lookup machinery and saving lots of time. ~23% speed-up on Kraken/ai-astar.js :^)
2023-07-08 17:43:26 +02:00
u32 m_cache_index { 0 };
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
};
LibJS/Bytecode: Support private class fields This is accomplished with two new instructions: - GetPrivateById - PutPrivateById Looks like 1616 new passes on test262. :^)
2023-06-23 08:16:17 +02:00
class GetPrivateById final : public Instruction {
public:
explicit GetPrivateById(IdentifierTableIndex property)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::GetPrivateById, sizeof(*this))
LibJS/Bytecode: Support private class fields This is accomplished with two new instructions: - GetPrivateById - PutPrivateById Looks like 1616 new passes on test262. :^)
2023-06-23 08:16:17 +02:00
, m_property(property)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
private:
IdentifierTableIndex m_property;
};
LibJS/Bytecode: Support `in` binary operator for private fields 11 new passes on test262. :^)
2023-07-05 12:42:50 +02:00
class HasPrivateId final : public Instruction {
public:
explicit HasPrivateId(IdentifierTableIndex property)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::HasPrivateId, sizeof(*this))
LibJS/Bytecode: Support `in` binary operator for private fields 11 new passes on test262. :^)
2023-07-05 12:42:50 +02:00
, m_property(property)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
private:
IdentifierTableIndex m_property;
};
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
enum class PropertyKind {
Getter,
Setter,
KeyValue,
LibJS/Bytecode: Always make own properties in object expressions When building an object from an object expression, we don't want to go through the full property setting machinery. This patch adds a new PropertyKind::DirectKeyValue for PutById which guarantees that the property becomes an own property. This fixes an issue where setting the "__proto__" property in object expressions wasn't working right. 12 new passes on test262. :^)
2023-07-10 08:44:28 +02:00
DirectKeyValue, // Used for Object expressions. Always sets an own property, never calls a setter.
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
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 20:47:07 +02:00
class PutById final : public Instruction {
public:
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
explicit PutById(Register base, IdentifierTableIndex property, PropertyKind kind = PropertyKind::KeyValue)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::PutById, sizeof(*this))
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
, m_base(base)
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
, m_property(property)
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
, 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 20:47:07 +02:00
{
}
LibJS/Bytecode: Support private class fields This is accomplished with two new instructions: - GetPrivateById - PutPrivateById Looks like 1616 new passes on test262. :^)
2023-06-23 08:16:17 +02:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
private:
Register m_base;
IdentifierTableIndex m_property;
PropertyKind m_kind;
};
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
class PutByIdWithThis final : public Instruction {
public:
PutByIdWithThis(Register base, Register this_value, IdentifierTableIndex property, PropertyKind kind = PropertyKind::KeyValue)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::PutByIdWithThis, sizeof(*this))
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
, m_base(base)
, m_this_value(this_value)
, m_property(property)
, m_kind(kind)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
private:
Register m_base;
Register m_this_value;
IdentifierTableIndex m_property;
PropertyKind m_kind;
};
LibJS/Bytecode: Support private class fields This is accomplished with two new instructions: - GetPrivateById - PutPrivateById Looks like 1616 new passes on test262. :^)
2023-06-23 08:16:17 +02:00
class PutPrivateById final : public Instruction {
public:
explicit PutPrivateById(Register base, IdentifierTableIndex property, PropertyKind kind = PropertyKind::KeyValue)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::PutPrivateById, sizeof(*this))
LibJS/Bytecode: Support private class fields This is accomplished with two new instructions: - GetPrivateById - PutPrivateById Looks like 1616 new passes on test262. :^)
2023-06-23 08:16:17 +02:00
, m_base(base)
, m_property(property)
, m_kind(kind)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Add PutById bytecode instruction for object property assignment Note that this is only used for non-computed accesses. Computed access is not yet implemented. :^)
2021-06-04 20:47:07 +02:00
private:
Register m_base;
LibJS: 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 15:34:30 +02:00
IdentifierTableIndex m_property;
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
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 20:47:07 +02: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 19:50:09 +01:00
class DeleteById final : public Instruction {
public:
explicit DeleteById(IdentifierTableIndex property)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::DeleteById, sizeof(*this))
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 19:50:09 +01:00
, m_property(property)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
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 19:50:09 +01:00
private:
IdentifierTableIndex m_property;
};
LibJS/Bytecode: Generate bytecode for deleting super properties
2023-07-06 17:10:40 -04:00
class DeleteByIdWithThis final : public Instruction {
public:
DeleteByIdWithThis(Register this_value, IdentifierTableIndex property)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::DeleteByIdWithThis, sizeof(*this))
LibJS/Bytecode: Generate bytecode for deleting super properties
2023-07-06 17:10:40 -04:00
, m_this_value(this_value)
, m_property(property)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
private:
Register m_this_value;
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-11 00:35:25 +02:00
class GetByValue final : public Instruction {
public:
explicit GetByValue(Register base)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::GetByValue, sizeof(*this))
LibJS: Basic bytecode support for computed member expressions Expressions like foo[1 + 2] now work, and you can assign to them as well! :^)
2021-06-11 00:35:25 +02:00
, m_base(base)
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Basic bytecode support for computed member expressions Expressions like foo[1 + 2] now work, and you can assign to them as well! :^)
2021-06-11 00:35:25 +02:00
LibJS/Bytecode: Move GetByValue implementation to CommonImplementations
2023-10-20 12:38:43 +02:00
Register base() const { return m_base; }
LibJS: Basic bytecode support for computed member expressions Expressions like foo[1 + 2] now work, and you can assign to them as well! :^)
2021-06-11 00:35:25 +02:00
private:
Register m_base;
};
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
class GetByValueWithThis final : public Instruction {
public:
GetByValueWithThis(Register base, Register this_value)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::GetByValueWithThis, sizeof(*this))
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
, m_base(base)
, m_this_value(this_value)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
private:
Register m_base;
Register m_this_value;
};
LibJS: Basic bytecode support for computed member expressions Expressions like foo[1 + 2] now work, and you can assign to them as well! :^)
2021-06-11 00:35:25 +02:00
class PutByValue final : public Instruction {
public:
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
PutByValue(Register base, Register property, PropertyKind kind = PropertyKind::KeyValue)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::PutByValue, sizeof(*this))
LibJS: Basic bytecode support for computed member expressions Expressions like foo[1 + 2] now work, and you can assign to them as well! :^)
2021-06-11 00:35:25 +02:00
, m_base(base)
, m_property(property)
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
, 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-11 00:35:25 +02:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
private:
Register m_base;
Register m_property;
PropertyKind m_kind;
};
class PutByValueWithThis final : public Instruction {
public:
PutByValueWithThis(Register base, Register property, Register this_value, PropertyKind kind = PropertyKind::KeyValue)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::PutByValueWithThis, sizeof(*this))
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
, m_base(base)
, m_property(property)
, m_this_value(this_value)
, m_kind(kind)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Basic bytecode support for computed member expressions Expressions like foo[1 + 2] now work, and you can assign to them as well! :^)
2021-06-11 00:35:25 +02:00
private:
Register m_base;
Register m_property;
LibJS/Bytecode: Use proper `this` for receiver in get/set for super expr Summary: Diff Tests: +14 ✅ -2 ❌ -12 📝
2023-07-02 19:26:31 +01:00
Register m_this_value;
LibJS: Implement bytecode generation for all ObjectExpression properties
2022-03-31 00:59:58 +04:30
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-11 00:35:25 +02: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 19:50:09 +01:00
class DeleteByValue final : public Instruction {
public:
DeleteByValue(Register base)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::DeleteByValue, sizeof(*this))
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 19:50:09 +01:00
, m_base(base)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
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 19:50:09 +01:00
private:
Register m_base;
};
LibJS/Bytecode: Generate bytecode for deleting super properties
2023-07-06 17:10:40 -04:00
class DeleteByValueWithThis final : public Instruction {
public:
DeleteByValueWithThis(Register base, Register this_value)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::DeleteByValueWithThis, sizeof(*this))
LibJS/Bytecode: Generate bytecode for deleting super properties
2023-07-06 17:10:40 -04:00
, m_base(base)
, m_this_value(this_value)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
private:
Register m_base;
Register m_this_value;
};
LibJS: Make JumpIf{True,False,Nullish} inherit from Jump This saves a few lines in LogicalExpression::generate_bytecode.
2021-06-08 11:28:27 +02:00
class Jump : public Instruction {
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
public:
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
constexpr static bool IsTerminator = true;
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
explicit Jump(Type type, Label taken_target, Optional<Label> nontaken_target = {})
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(type, sizeof(*this))
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
, m_true_target(move(taken_target))
, m_false_target(move(nontaken_target))
LibJS: Make JumpIf{True,False,Nullish} inherit from Jump This saves a few lines in LogicalExpression::generate_bytecode.
2021-06-08 11:28:27 +02:00
{
}
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
explicit Jump(Label taken_target, Optional<Label> nontaken_target = {})
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::Jump, sizeof(*this))
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
, m_true_target(move(taken_target))
, m_false_target(move(nontaken_target))
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_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 20:40:20 +04:30
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 06:49:58 +04:30
protected:
Optional<Label> m_true_target;
Optional<Label> m_false_target;
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
};
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
class JumpConditional final : public Jump {
LibJS: Generate bytecode for do...while statements :^) This was quite straightforward using the same label/jump machinery that we added for while statements. The main addition here is a new JumpIfTrue bytecode instruction.
2021-06-04 12:20:44 +02:00
public:
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
explicit JumpConditional(Label true_target, Label 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 06:49:58 +04:30
: Jump(Type::JumpConditional, move(true_target), move(false_target))
LibJS: Generate bytecode for do...while statements :^) This was quite straightforward using the same label/jump machinery that we added for while statements. The main addition here is a new JumpIfTrue bytecode instruction.
2021-06-04 12:20:44 +02:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Generate bytecode for do...while statements :^) This was quite straightforward using the same label/jump machinery that we added for while statements. The main addition here is a new JumpIfTrue bytecode instruction.
2021-06-04 12:20:44 +02:00
};
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
class JumpNullish final : public Jump {
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
public:
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
explicit JumpNullish(Label true_target, Label 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 06:49:58 +04:30
: Jump(Type::JumpNullish, move(true_target), move(false_target))
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
};
LibJS: Add JumpUndefined bytecode
2021-06-13 12:24:40 -07:00
class JumpUndefined final : public Jump {
public:
LibJS: Remove almost all uses of Op::Jump::set_targets() We should initialize jump targets when constructing the jump instruction instead of doing it later. This was already the case in all construction sites but one. This first patch converts all those sites to pass final targets to the constructor directly.
2023-09-28 12:43:11 +02:00
explicit JumpUndefined(Label true_target, Label false_target)
LibJS: Add JumpUndefined bytecode
2021-06-13 12:24:40 -07:00
: 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 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Add JumpUndefined bytecode
2021-06-13 12:24:40 -07:00
};
LibJS/Bytecode: Rename Call and SuperCall to &WithArgumentArray Forcing every function call to allocate a new Array just to accommodate spread parameters is not very nice, so let's start moving towards making this a special case rather than the general (and only) case.
2023-07-02 15:59:54 +02:00
enum class CallType {
Call,
Construct,
DirectEval,
};
LibJS: Very basic support for "new" construction in bytecode VM This patch adds a CallType to the Bytecode::Op::Call instruction, which can be either Call or Construct. We then generate Construct calls for the NewExpression AST node. When executed, these get fed into VM::construct().
2021-06-10 23:01:49 +02:00
LibJS/Bytecode: Add Call opcode for fixed-argument-count calls This avoids the overhead of allocating a new Array on every function call, saving a substantial amount of time and avoiding GC thrash. This patch only makes use of Op::Call in CallExpression. There are other places we should codegen this op. We should also do the same for super expression calls. ~5% speed-up on Kraken/stanford-crypto-ccm.js
2023-07-02 16:33:00 +02:00
class Call final : public Instruction {
public:
Call(CallType type, Register callee, Register this_value, Register first_argument, u32 argument_count, Optional<StringTableIndex> expression_string = {})
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::Call, sizeof(*this))
LibJS/Bytecode: Add Call opcode for fixed-argument-count calls This avoids the overhead of allocating a new Array on every function call, saving a substantial amount of time and avoiding GC thrash. This patch only makes use of Op::Call in CallExpression. There are other places we should codegen this op. We should also do the same for super expression calls. ~5% speed-up on Kraken/stanford-crypto-ccm.js
2023-07-02 16:33:00 +02:00
, m_callee(callee)
, m_this_value(this_value)
, m_first_argument(first_argument)
, m_argument_count(argument_count)
, m_type(type)
, m_expression_string(expression_string)
{
}
CallType call_type() const { return m_type; }
Register callee() const { return m_callee; }
Register this_value() const { return m_this_value; }
Optional<StringTableIndex> const& expression_string() const { return m_expression_string; }
LibJS: Handle `Call`s argument range during `EliminateLoads` pass Otherwise we could forget to emit stores those registers, thinking that they are only directly accessed.
2023-07-03 15:15:24 +02:00
Register first_argument() const { return m_first_argument; }
u32 argument_count() const { return m_argument_count; }
LibJS/Bytecode: Add Call opcode for fixed-argument-count calls This avoids the overhead of allocating a new Array on every function call, saving a substantial amount of time and avoiding GC thrash. This patch only makes use of Op::Call in CallExpression. There are other places we should codegen this op. We should also do the same for super expression calls. ~5% speed-up on Kraken/stanford-crypto-ccm.js
2023-07-02 16:33:00 +02:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
private:
Register m_callee;
Register m_this_value;
Register m_first_argument;
u32 m_argument_count { 0 };
CallType m_type;
Optional<StringTableIndex> m_expression_string;
};
LibJS/Bytecode: Rename Call and SuperCall to &WithArgumentArray Forcing every function call to allocate a new Array just to accommodate spread parameters is not very nice, so let's start moving towards making this a special case rather than the general (and only) case.
2023-07-02 15:59:54 +02:00
class CallWithArgumentArray final : public Instruction {
public:
CallWithArgumentArray(CallType type, Register callee, Register this_value, Optional<StringTableIndex> expression_string = {})
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::CallWithArgumentArray, sizeof(*this))
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
, m_callee(callee)
, m_this_value(this_value)
LibJS: Very basic support for "new" construction in bytecode VM This patch adds a CallType to the Bytecode::Op::Call instruction, which can be either Call or Construct. We then generate Construct calls for the NewExpression AST node. When executed, these get fed into VM::construct().
2021-06-10 23:01:49 +02:00
, m_type(type)
LibJS: Forward a string aproximation of the CallExpression to Call Ops This gives us better debug output when analysing calls to `undefined` and also fixes multiple test-js cases expecting an `(evaluated from $Expression)` in the error message. This also refactors out the generation of that string, to avoid code duplication with the AST interpreter.
2022-10-01 01:36:06 +02:00
, m_expression_string(expression_string)
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
{
}
LibJS/Bytecode: Add Call opcode for fixed-argument-count calls This avoids the overhead of allocating a new Array on every function call, saving a substantial amount of time and avoiding GC thrash. This patch only makes use of Op::Call in CallExpression. There are other places we should codegen this op. We should also do the same for super expression calls. ~5% speed-up on Kraken/stanford-crypto-ccm.js
2023-07-02 16:33:00 +02:00
CallType call_type() const { return m_type; }
Register callee() const { return m_callee; }
Register this_value() const { return m_this_value; }
Optional<StringTableIndex> const& expression_string() const { return m_expression_string; }
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
private:
Register m_callee;
Register m_this_value;
LibJS: Very basic support for "new" construction in bytecode VM This patch adds a CallType to the Bytecode::Op::Call instruction, which can be either Call or Construct. We then generate Construct calls for the NewExpression AST node. When executed, these get fed into VM::construct().
2021-06-10 23:01:49 +02:00
CallType m_type;
LibJS: Forward a string aproximation of the CallExpression to Call Ops This gives us better debug output when analysing calls to `undefined` and also fixes multiple test-js cases expecting an `(evaluated from $Expression)` in the error message. This also refactors out the generation of that string, to avoid code duplication with the AST interpreter.
2022-10-01 01:36:06 +02:00
Optional<StringTableIndex> m_expression_string;
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
};
LibJS/Bytecode: Rename Call and SuperCall to &WithArgumentArray Forcing every function call to allocate a new Array just to accommodate spread parameters is not very nice, so let's start moving towards making this a special case rather than the general (and only) case.
2023-07-02 15:59:54 +02:00
class SuperCallWithArgumentArray : public Instruction {
LibJS: Implement SuperCall for the Bytecode-VM
2022-08-30 18:03:02 +02:00
public:
LibJS/Bytecode: Rename Call and SuperCall to &WithArgumentArray Forcing every function call to allocate a new Array just to accommodate spread parameters is not very nice, so let's start moving towards making this a special case rather than the general (and only) case.
2023-07-02 15:59:54 +02:00
explicit SuperCallWithArgumentArray(bool is_synthetic)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::SuperCallWithArgumentArray, sizeof(*this))
LibJS: Implement SuperCall for the Bytecode-VM
2022-08-30 18:03:02 +02:00
, m_is_synthetic(is_synthetic)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Implement SuperCall for the Bytecode-VM
2022-08-30 18:03:02 +02:00
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 15:42:13 -03:00
class NewClass final : public Instruction {
public:
LibJS: Use the IdentifierTable for NewFunction and NewClass lhs names This makes them trivially copyable, which is an assumption multiple optimizations use when rebuilding the instruction stream. This fixes most optimized crashes in the test262 suite.
2023-06-28 18:17:13 +02:00
explicit NewClass(ClassExpression const& class_expression, Optional<IdentifierTableIndex> lhs_name)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::NewClass, sizeof(*this))
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 15:42:13 -03:00
, m_class_expression(class_expression)
LibJS: Use the IdentifierTable for NewFunction and NewClass lhs names This makes them trivially copyable, which is an assumption multiple optimizations use when rebuilding the instruction stream. This fixes most optimized crashes in the test262 suite.
2023-06-28 18:17:13 +02:00
, m_lhs_name(lhs_name)
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 15:42:13 -03:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) 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 15:42:13 -03:00
private:
ClassExpression const& m_class_expression;
LibJS: Use the IdentifierTable for NewFunction and NewClass lhs names This makes them trivially copyable, which is an assumption multiple optimizations use when rebuilding the instruction stream. This fixes most optimized crashes in the test262 suite.
2023-06-28 18:17:13 +02:00
Optional<IdentifierTableIndex> m_lhs_name;
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 15:42:13 -03:00
};
LibJS: Perform function instantiation in bytecode This replaces Bytecode::Op::EnterScope with a new NewFunction op that instantiates a ScriptFunction from a given FunctionNode (AST). This is then used to instantiate the local functions directly from bytecode when entering a ScopeNode. :^)
2021-06-10 00:49:23 +02:00
class NewFunction final : public Instruction {
LibJS: Add a new EnterScope bytecode instruction This is intended to perform the same duties as enter_scope() does in the AST tree-walk interpreter: - Hoisted function declaration processing - Hoisted variable declaration processing - ... maybe more This first cut only implements the function declaration processing.
2021-06-05 15:14:09 +02:00
public:
LibJS: Use the IdentifierTable for NewFunction and NewClass lhs names This makes them trivially copyable, which is an assumption multiple optimizations use when rebuilding the instruction stream. This fixes most optimized crashes in the test262 suite.
2023-06-28 18:17:13 +02:00
explicit NewFunction(FunctionExpression const& function_node, Optional<IdentifierTableIndex> lhs_name, Optional<Register> home_object = {})
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::NewFunction, sizeof(*this))
LibJS: Perform function instantiation in bytecode This replaces Bytecode::Op::EnterScope with a new NewFunction op that instantiates a ScriptFunction from a given FunctionNode (AST). This is then used to instantiate the local functions directly from bytecode when entering a ScopeNode. :^)
2021-06-10 00:49:23 +02:00
, m_function_node(function_node)
LibJS: Use the IdentifierTable for NewFunction and NewClass lhs names This makes them trivially copyable, which is an assumption multiple optimizations use when rebuilding the instruction stream. This fixes most optimized crashes in the test262 suite.
2023-06-28 18:17:13 +02:00
, m_lhs_name(lhs_name)
LibJS/Bytecode: Set "home object" of functions within object expression We manage this by having a stack of home objects in Generator, and then adding an optional home object parameter to the NewFunction instruction.
2023-06-16 10:25:05 +02:00
, m_home_object(move(home_object))
LibJS: Add a new EnterScope bytecode instruction This is intended to perform the same duties as enter_scope() does in the AST tree-walk interpreter: - Hoisted function declaration processing - Hoisted variable declaration processing - ... maybe more This first cut only implements the function declaration processing.
2021-06-05 15:14:09 +02:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Add a new EnterScope bytecode instruction This is intended to perform the same duties as enter_scope() does in the AST tree-walk interpreter: - Hoisted function declaration processing - Hoisted variable declaration processing - ... maybe more This first cut only implements the function declaration processing.
2021-06-05 15:14:09 +02:00
private:
LibJS/Bytecode: Add codegen for "named evaluation if anonymous function" This gives anonymous functions the name from the LHS they are being assigned to. 171 new passes on test262. :^)
2023-06-23 14:27:42 +02:00
FunctionExpression const& m_function_node;
LibJS: Use the IdentifierTable for NewFunction and NewClass lhs names This makes them trivially copyable, which is an assumption multiple optimizations use when rebuilding the instruction stream. This fixes most optimized crashes in the test262 suite.
2023-06-28 18:17:13 +02:00
Optional<IdentifierTableIndex> m_lhs_name;
LibJS/Bytecode: Set "home object" of functions within object expression We manage this by having a stack of home objects in Generator, and then adding an optional home object parameter to the NewFunction instruction.
2023-06-16 10:25:05 +02:00
Optional<Register> m_home_object;
LibJS: Add a new EnterScope bytecode instruction This is intended to perform the same duties as enter_scope() does in the AST tree-walk interpreter: - Hoisted function declaration processing - Hoisted variable declaration processing - ... maybe more This first cut only implements the function declaration processing.
2021-06-05 15:14:09 +02:00
};
LibJS/Bytecode: Leave BlockDeclarationInstantiation in C++ Instead of implementing this AO in bytecode, we now have an instruction for it that simply invokes the C++ implementation. This allows us to simplify Bytecode::Generator quite a bit by removing all the variable scope tracking.
2023-06-16 16:34:47 +02:00
class BlockDeclarationInstantiation final : public Instruction {
public:
explicit BlockDeclarationInstantiation(ScopeNode const& scope_node)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::BlockDeclarationInstantiation, sizeof(*this))
LibJS/Bytecode: Leave BlockDeclarationInstantiation in C++ Instead of implementing this AO in bytecode, we now have an instruction for it that simply invokes the C++ implementation. This allows us to simplify Bytecode::Generator quite a bit by removing all the variable scope tracking.
2023-06-16 16:34:47 +02:00
, m_scope_node(scope_node)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
private:
ScopeNode const& m_scope_node;
};
LibJS: Compile ScriptFunctions into bytecode and run them that way :^) If there's a current Bytecode::Interpreter in action, ScriptFunction will now compile itself into bytecode and execute in that context. This patch also adds the Return bytecode instruction so that we can actually return values from called functions. :^) Return values are propagated from callee to caller via the caller's $0 register. Bytecode::Interpreter now keeps a stack of register "windows". These are not very efficient, but it should be pretty straightforward to convert them to e.g a sliding register window architecture later on. This is pretty dang cool! :^)
2021-06-05 15:53:36 +02:00
class Return final : public Instruction {
public:
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
constexpr static bool IsTerminator = true;
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
Return()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::Return, sizeof(*this))
LibJS: Compile ScriptFunctions into bytecode and run them that way :^) If there's a current Bytecode::Interpreter in action, ScriptFunction will now compile itself into bytecode and execute in that context. This patch also adds the Return bytecode instruction so that we can actually return values from called functions. :^) Return values are propagated from callee to caller via the caller's $0 register. Bytecode::Interpreter now keeps a stack of register "windows". These are not very efficient, but it should be pretty straightforward to convert them to e.g a sliding register window architecture later on. This is pretty dang cool! :^)
2021-06-05 15:53:36 +02:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Compile ScriptFunctions into bytecode and run them that way :^) If there's a current Bytecode::Interpreter in action, ScriptFunction will now compile itself into bytecode and execute in that context. This patch also adds the Return bytecode instruction so that we can actually return values from called functions. :^) Return values are propagated from callee to caller via the caller's $0 register. Bytecode::Interpreter now keeps a stack of register "windows". These are not very efficient, but it should be pretty straightforward to convert them to e.g a sliding register window architecture later on. This is pretty dang cool! :^)
2021-06-05 15:53:36 +02:00
};
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
class Increment final : public Instruction {
public:
Increment()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::Increment, sizeof(*this))
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
};
class Decrement final : public Instruction {
public:
Decrement()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::Decrement, sizeof(*this))
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
};
LibJS/Bytecode: Perform ToNumeric on accumulator before postfix inc/dec This ensures we get the expected behavior of code like: let a = [] let b = a++ (Where b should be 0, not [], because JavaScript.)
2023-06-16 10:51:40 +02:00
class ToNumeric final : public Instruction {
public:
ToNumeric()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::ToNumeric, sizeof(*this))
LibJS/Bytecode: Perform ToNumeric on accumulator before postfix inc/dec This ensures we get the expected behavior of code like: let a = [] let b = a++ (Where b should be 0, not [], because JavaScript.)
2023-06-16 10:51:40 +02:00
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
};
LibJS: Generate bytecode for throw statements
2021-06-09 18:18:56 +02:00
class Throw final : public Instruction {
public:
constexpr static bool IsTerminator = true;
Throw()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::Throw, sizeof(*this))
LibJS: Generate bytecode for throw statements
2021-06-09 18:18:56 +02:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Generate bytecode for throw statements
2021-06-09 18:18:56 +02:00
};
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
class ThrowIfNotObject final : public Instruction {
public:
ThrowIfNotObject()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::ThrowIfNotObject, sizeof(*this))
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
};
LibJS/Bytecode: Throw on destructuring object assignment to nullish LHS 24 new passes on test262. :^)
2023-06-25 08:50:07 +02:00
class ThrowIfNullish final : public Instruction {
public:
ThrowIfNullish()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::ThrowIfNullish, sizeof(*this))
LibJS/Bytecode: Throw on destructuring object assignment to nullish LHS 24 new passes on test262. :^)
2023-06-25 08:50:07 +02:00
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
};
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
class EnterUnwindContext final : public Instruction {
public:
LibJS: Make EnterUnwindContext a terminator op Otherwise a basic block could have multiple outgoing edges without having much reason to do so.
2021-06-13 20:39:40 +04:30
constexpr static bool IsTerminator = true;
EnterUnwindContext(Label entry_point, Optional<Label> handler_target, Optional<Label> finalizer_target)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::EnterUnwindContext, sizeof(*this))
LibJS: Make EnterUnwindContext a terminator op Otherwise a basic block could have multiple outgoing edges without having much reason to do so.
2021-06-13 20:39:40 +04:30
, m_entry_point(move(entry_point))
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
, m_handler_target(move(handler_target))
, m_finalizer_target(move(finalizer_target))
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_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 20:40:20 +04:30
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 15:04:38 +02:00
private:
LibJS: Make EnterUnwindContext a terminator op Otherwise a basic block could have multiple outgoing edges without having much reason to do so.
2021-06-13 20:39:40 +04:30
Label m_entry_point;
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
Optional<Label> m_handler_target;
Optional<Label> m_finalizer_target;
};
LibJS: Generate unwind chains for break in Bytecode This uses a newly added instruction `ScheduleJump` This instruction tells the finally proceeding it, that instead of jumping to it's next block it should jump to the designated block.
2022-11-25 16:15:34 +01:00
class ScheduleJump final : public Instruction {
public:
// Note: We use this instruction to tell the next `finally` block to
// continue execution with a specific break/continue target;
// FIXME: We currently don't clear the interpreter internal flag, when we change
// the control-flow (`break`, `continue`) in a finally-block,
// FIXME: .NET on x86_64 uses a call to the finally instead, which could make this
// easier, at the cost of making control-flow changes (`break`, `continue`, `return`)
// in the finally-block more difficult, but as stated above, those
// aren't handled 100% correctly at the moment anyway
// It might be worth investigating a similar mechanism
constexpr static bool IsTerminator = true;
ScheduleJump(Label target)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::ScheduleJump, sizeof(*this))
LibJS: Generate unwind chains for break in Bytecode This uses a newly added instruction `ScheduleJump` This instruction tells the finally proceeding it, that instead of jumping to it's next block it should jump to the designated block.
2022-11-25 16:15:34 +01:00
, m_target(target)
{
}
Label target() const { return m_target; }
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
private:
Label m_target;
};
LibJS/Bytecode: Simplify creating/leaving lexical environment Since we no longer need to create or leave var environments directly in bytecode, we can streamline the two instructions by making them always operate on the lexical environment.
2023-06-16 16:43:24 +02:00
class LeaveLexicalEnvironment final : public Instruction {
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 19:48:45 +03:30
public:
LibJS/Bytecode: Simplify creating/leaving lexical environment Since we no longer need to create or leave var environments directly in bytecode, we can streamline the two instructions by making them always operate on the lexical environment.
2023-06-16 16:43:24 +02:00
LeaveLexicalEnvironment()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::LeaveLexicalEnvironment, sizeof(*this))
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 19:48:45 +03:30
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) 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 19:48:45 +03:30
};
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
class LeaveUnwindContext final : public Instruction {
public:
LeaveUnwindContext()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::LeaveUnwindContext, sizeof(*this))
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
};
class ContinuePendingUnwind final : public Instruction {
public:
constexpr static bool IsTerminator = true;
LibJS: Fix all clang-tidy warnings in Bytecode/Op.h - Add missing explicit to constructors - Use move() where appropriate
2021-06-12 11:22:46 +02:00
explicit ContinuePendingUnwind(Label resume_target)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::ContinuePendingUnwind, sizeof(*this))
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
, 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 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_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 20:40:20 +04:30
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 15:04:38 +02:00
private:
Label m_resume_target;
};
LibJS: Generate bytecode for entering nested lexical environments This adds a new PushLexicalEnvironment instruction that creates a new LexicalEnvironment and pushes it on the VM's scope stack. There is no corresponding PopLexicalEnvironment instruction yet, so this will behave incorrectly with let/const scopes for example.
2021-06-10 22:12:21 +02:00
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
class Yield final : public Instruction {
public:
constexpr static bool IsTerminator = true;
explicit Yield(Label continuation_label)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::Yield, sizeof(*this))
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
, m_continuation_label(continuation_label)
{
}
Everywhere: Stop shoving things into ::std and mentioning them as such Note that this still keeps the old behaviour of putting things in std by default on serenity so the tools can be happy, but if USING_AK_GLOBALLY is unset, AK behaves like a good citizen and doesn't try to put things in the ::std namespace. std::nothrow_t and its friends get to stay because I'm being told that compilers assume things about them and I can't yeet them into a different namespace...for now.
2022-12-13 10:29:30 +03:30
explicit Yield(nullptr_t)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::Yield, sizeof(*this))
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_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 20:40:20 +04:30
auto& continuation() const { return m_continuation_label; }
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
private:
Optional<Label> m_continuation_label;
};
LibJS/Bytecode: Add Await and AsyncIteratorClose instructions
2023-07-14 21:42:43 +01:00
class Await final : public Instruction {
public:
constexpr static bool IsTerminator = true;
explicit Await(Label continuation_label)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::Await, sizeof(*this))
LibJS/Bytecode: Add Await and AsyncIteratorClose instructions
2023-07-14 21:42:43 +01:00
, m_continuation_label(continuation_label)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
auto& continuation() const { return m_continuation_label; }
private:
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 12:24:46 +02: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 22:12:21 +02: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 12:24:46 +02:00
explicit PushDeclarativeEnvironment(HashMap<u32, Variable> variables)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::PushDeclarativeEnvironment, sizeof(*this))
LibJS: Generate bytecode for entering nested lexical environments This adds a new PushLexicalEnvironment instruction that creates a new LexicalEnvironment and pushes it on the VM's scope stack. There is no corresponding PopLexicalEnvironment instruction yet, so this will behave incorrectly with let/const scopes for example.
2021-06-10 22:12:21 +02:00
, m_variables(move(variables))
{
}
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Generate bytecode for entering nested lexical environments This adds a new PushLexicalEnvironment instruction that creates a new LexicalEnvironment and pushes it on the VM's scope stack. There is no corresponding PopLexicalEnvironment instruction yet, so this will behave incorrectly with let/const scopes for example.
2021-06-10 22:12:21 +02:00
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
private:
LibJS: Generate bytecode for entering nested lexical environments This adds a new PushLexicalEnvironment instruction that creates a new LexicalEnvironment and pushes it on the VM's scope stack. There is no corresponding PopLexicalEnvironment instruction yet, so this will behave incorrectly with let/const scopes for example.
2021-06-10 22:12:21 +02:00
HashMap<u32, Variable> m_variables;
};
LibJS: Add LoadArgument bytecode instruction for fast argument access This is generated for Identifier nodes that represent a function argument variable. It loads a given argument index from the current call frame into the accumulator.
2021-06-14 09:37:35 +02:00
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
class GetIterator final : public Instruction {
public:
LibJS/Bytecode: Implement for await of Summary: Diff Tests: +391 ✅ +15 ❌ +2 💥️ -408 📝
2023-06-27 19:24:34 +01:00
GetIterator(IteratorHint hint = IteratorHint::Sync)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::GetIterator, sizeof(*this))
LibJS/Bytecode: Implement for await of Summary: Diff Tests: +391 ✅ +15 ❌ +2 💥️ -408 📝
2023-06-27 19:24:34 +01:00
, m_hint(hint)
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS/Bytecode: Implement for await of Summary: Diff Tests: +391 ✅ +15 ❌ +2 💥️ -408 📝
2023-06-27 19:24:34 +01:00
private:
IteratorHint m_hint { IteratorHint::Sync };
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
};
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
class GetMethod final : public Instruction {
public:
GetMethod(IdentifierTableIndex property)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::GetMethod, sizeof(*this))
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
, m_property(property)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
private:
IdentifierTableIndex m_property;
};
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 20:18:19 +03:30
class GetObjectPropertyIterator final : public Instruction {
public:
GetObjectPropertyIterator()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::GetObjectPropertyIterator, sizeof(*this))
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 20:18:19 +03:30
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) 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 20:18:19 +03:30
};
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
class IteratorClose final : public Instruction {
public:
IteratorClose(Completion::Type completion_type, Optional<Value> completion_value)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::IteratorClose, sizeof(*this))
LibJS/Bytecode: Implement yield*
2022-12-09 18:48:57 +00:00
, m_completion_type(completion_type)
, m_completion_value(completion_value)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
private:
Completion::Type m_completion_type { Completion::Type::Normal };
Optional<Value> m_completion_value;
};
LibJS/Bytecode: Add Await and AsyncIteratorClose instructions
2023-07-14 21:42:43 +01:00
class AsyncIteratorClose final : public Instruction {
public:
AsyncIteratorClose(Completion::Type completion_type, Optional<Value> completion_value)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::AsyncIteratorClose, sizeof(*this))
LibJS/Bytecode: Add Await and AsyncIteratorClose instructions
2023-07-14 21:42:43 +01:00
, m_completion_type(completion_type)
, m_completion_value(completion_value)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
private:
Completion::Type m_completion_type { Completion::Type::Normal };
Optional<Value> m_completion_value;
};
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
class IteratorNext final : public Instruction {
public:
IteratorNext()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::IteratorNext, sizeof(*this))
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
};
class IteratorResultDone final : public Instruction {
public:
IteratorResultDone()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::IteratorResultDone, sizeof(*this))
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
};
class IteratorResultValue final : public Instruction {
public:
IteratorResultValue()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::IteratorResultValue, sizeof(*this))
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
};
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 14:43:00 +02:00
class ResolveThisBinding final : public Instruction {
public:
explicit ResolveThisBinding()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::ResolveThisBinding, sizeof(*this))
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 14:43:00 +02:00
{
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) 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 14:43:00 +02:00
};
LibJS/Bytecode: Implement initial support for super member expressions
2023-05-15 18:45:16 +01:00
class ResolveSuperBase final : public Instruction {
public:
explicit ResolveSuperBase()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::ResolveSuperBase, sizeof(*this))
LibJS/Bytecode: Implement initial support for super member expressions
2023-05-15 18:45:16 +01:00
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
};
LibJS/Bytecode: Add support for new.target
2022-03-19 19:40:21 +00:00
class GetNewTarget final : public Instruction {
public:
explicit GetNewTarget()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::GetNewTarget, sizeof(*this))
LibJS/Bytecode: Add support for new.target
2022-03-19 19:40:21 +00:00
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
LibJS/Bytecode: Add support for new.target
2022-03-19 19:40:21 +00:00
};
LibJS: Implement import.meta for bytecode
2023-07-11 23:07:12 -04:00
class GetImportMeta final : public Instruction {
public:
explicit GetImportMeta()
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::GetImportMeta, sizeof(*this))
LibJS: Implement import.meta for bytecode
2023-07-11 23:07:12 -04:00
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) 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 23:12:22 +01:00
class TypeofVariable final : public Instruction {
public:
explicit TypeofVariable(IdentifierTableIndex identifier)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::TypeofVariable, sizeof(*this))
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 23:12:22 +01:00
, m_identifier(identifier)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) 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 23:12:22 +01:00
private:
IdentifierTableIndex m_identifier;
};
LibJS: Update bytecode generator to use local variables - Update ECMAScriptFunctionObject::function_declaration_instantiation to initialize local variables - Introduce GetLocal, SetLocal, TypeofLocal that will be used to operate on local variables. - Update bytecode generator to emit instructions for local variables
2023-07-05 02:17:10 +02:00
class TypeofLocal final : public Instruction {
public:
explicit TypeofLocal(size_t index)
LibJS: Store bytecode instruction length in instruction itself Instead of running a big switch statement on the opcode when checking how long an instruction is, we now simply store that in a member variable at construction time for instant access. This yields a 10.2% speed-up on Kraken/ai-astar :^)
2023-09-13 21:32:51 +02:00
: Instruction(Type::TypeofLocal, sizeof(*this))
LibJS: Update bytecode generator to use local variables - Update ECMAScriptFunctionObject::function_declaration_instantiation to initialize local variables - Introduce GetLocal, SetLocal, TypeofLocal that will be used to operate on local variables. - Update bytecode generator to emit instructions for local variables
2023-07-05 02:17:10 +02:00
, m_index(index)
{
}
ThrowCompletionOr<void> execute_impl(Bytecode::Interpreter&) const;
DeprecatedString to_deprecated_string_impl(Bytecode::Executable const&) const;
private:
size_t m_index;
};
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
}
LibJS: Move Bytecode::Instruction::execute() to the Op.h header ..and make sure it always gets inlined in the interpreter loop.
2021-06-09 09:19:34 +02:00
namespace JS::Bytecode {
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01: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 09:19:34 +02: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 18:08:12 +04:30
return static_cast<Bytecode::Op::op const&>(*this).execute_impl(interpreter);
LibJS: Move Bytecode::Instruction::execute() to the Op.h header ..and make sure it always gets inlined in the interpreter loop.
2021-06-09 09:19:34 +02:00
switch (type()) {
ENUMERATE_BYTECODE_OPS(__BYTECODE_OP)
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 20:40:20 +04:30
default:
VERIFY_NOT_REACHED();
}
#undef __BYTECODE_OP
}
LibJS: Move Bytecode::Instruction::execute() to the Op.h header ..and make sure it always gets inlined in the interpreter loop.
2021-06-09 09:19:34 +02:00
}
Reference in a new issue Copy permalink