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

704 lines
24 KiB
C++
Raw Normal View History

LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
/*
* Copyright (c) 2021, Andreas Kling <kling@serenityos.org>
LibJS: Add bytecode generation for BinaryOp::In
2021-06-07 21:13:37 +01:00
* Copyright (c) 2021, Linus Groh <linusg@serenityos.org>
LibJS: Generate bytecode for throw statements
2021-06-09 18:18:56 +02:00
* Copyright (c) 2021, Gunnar Beutner <gbeutner@serenityos.org>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
#include <AK/HashTable.h>
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
#include <LibJS/AST.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/Interpreter.h>
#include <LibJS/Bytecode/Op.h>
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
#include <LibJS/Runtime/Array.h>
LibJS: Implement bytecode generation for BigInts
2021-06-08 07:59:25 +02:00
#include <LibJS/Runtime/BigInt.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/DeclarativeEnvironment.h>
#include <LibJS/Runtime/Environment.h>
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
#include <LibJS/Runtime/GlobalObject.h>
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
#include <LibJS/Runtime/IteratorOperations.h>
LibJS: Rename ScriptFunction => OrdinaryFunctionObject These are basically what the spec calls "ordinary function objects", so let's have the name reflect that. :^)
2021-06-27 22:15:58 +02:00
#include <LibJS/Runtime/OrdinaryFunctionObject.h>
LibJS: Add bytecode support for regexp literals
2021-06-19 17:17:40 -07:00
#include <LibJS/Runtime/RegExpObject.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: 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
namespace JS::Bytecode {
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
String Instruction::to_string(Bytecode::Executable const& executable) 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
{
#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).to_string_impl(executable);
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
switch (type()) {
ENUMERATE_BYTECODE_OPS(__BYTECODE_OP)
default:
VERIFY_NOT_REACHED();
}
#undef __BYTECODE_OP
}
}
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 {
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void Load::execute_impl(Bytecode::Interpreter& interpreter) 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: 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
interpreter.accumulator() = interpreter.reg(m_src);
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: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void LoadImmediate::execute_impl(Bytecode::Interpreter& interpreter) 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: 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
interpreter.accumulator() = m_value;
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void Store::execute_impl(Bytecode::Interpreter& interpreter) 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
{
interpreter.reg(m_dst) = interpreter.accumulator();
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: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
static Value abstract_inequals(GlobalObject& global_object, Value src1, Value src2)
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: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
return Value(!abstract_eq(global_object, src1, src2));
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: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
static Value abstract_equals(GlobalObject& global_object, Value src1, Value src2)
LibJS: Add Sub bytecode instruction (subtract values)
2021-06-03 18:32:33 +02:00
{
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
return Value(abstract_eq(global_object, src1, src2));
LibJS: Add Sub bytecode instruction (subtract values)
2021-06-03 18:32:33 +02:00
}
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
static Value typed_inequals(GlobalObject&, Value src1, Value src2)
LibJS: Add bytecode instructions for multiplication and division
2021-06-07 19:17:20 +02:00
{
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
return Value(!strict_eq(src1, src2));
LibJS: Add bytecode instructions for multiplication and division
2021-06-07 19:17:20 +02:00
}
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
static Value typed_equals(GlobalObject&, Value src1, Value src2)
LibJS: Add bytecode instructions for multiplication and division
2021-06-07 19:17:20 +02:00
{
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
return Value(strict_eq(src1, src2));
LibJS: Add bytecode instructions for multiplication and division
2021-06-07 19:17:20 +02: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
#define JS_DEFINE_COMMON_BINARY_OP(OpTitleCase, op_snake_case) \
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void OpTitleCase::execute_impl(Bytecode::Interpreter& interpreter) 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
{ \
auto lhs = interpreter.reg(m_lhs_reg); \
auto rhs = interpreter.accumulator(); \
interpreter.accumulator() = op_snake_case(interpreter.global_object(), lhs, rhs); \
} \
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
String OpTitleCase::to_string_impl(Bytecode::Executable const&) const \
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
{ \
LibJS: Simplify the way we stringify bytecode instructions For instructions that only have a single operand, omit the operand name since it's implied anyway.
2021-06-09 11:06:11 +02:00
return String::formatted(#OpTitleCase " {}", m_lhs_reg); \
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
}
LibJS: Add bytecode generation for BinaryOp::In
2021-06-07 21:13:37 +01:00
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_DEFINE_COMMON_BINARY_OP)
LibJS: Add bytecode generation for BinaryOp::InstanceOf
2021-06-07 21:18:19 +01:00
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
static Value not_(GlobalObject&, Value value)
LibJS: Add bytecode generation for BinaryOp::In
2021-06-07 21:13:37 +01:00
{
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
return Value(!value.to_boolean());
LibJS: Add bytecode generation for BinaryOp::In
2021-06-07 21:13:37 +01:00
}
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
static Value typeof_(GlobalObject& global_object, Value value)
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
{
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
return js_string(global_object.vm(), value.typeof());
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01: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
#define JS_DEFINE_COMMON_UNARY_OP(OpTitleCase, op_snake_case) \
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void OpTitleCase::execute_impl(Bytecode::Interpreter& interpreter) 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
{ \
interpreter.accumulator() = op_snake_case(interpreter.global_object(), interpreter.accumulator()); \
} \
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
String OpTitleCase::to_string_impl(Bytecode::Executable const&) const \
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
{ \
return #OpTitleCase; \
LibJS: Use macros to generate the common unary/binary bytecode ops
2021-06-07 23:08:35 +02:00
}
LibJS: Add bytecode instructions for a bunch of unary operators ~, !, +, -, typeof, and void.
2021-06-07 19:53:47 +01:00
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_DEFINE_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: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void NewBigInt::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Implement bytecode generation for BigInts
2021-06-08 07:59:25 +02: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
interpreter.accumulator() = js_bigint(interpreter.vm().heap(), m_bigint);
LibJS: Implement bytecode generation for BigInts
2021-06-08 07:59:25 +02:00
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void NewArray::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
{
Vector<Value> elements;
elements.ensure_capacity(m_element_count);
for (size_t i = 0; i < m_element_count; i++)
elements.append(interpreter.reg(m_elements[i]));
interpreter.accumulator() = Array::create_from(interpreter.global_object(), elements);
}
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
void IteratorToArray::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& global_object = interpreter.global_object();
auto& vm = interpreter.vm();
auto iterator = interpreter.accumulator().to_object(global_object);
if (vm.exception())
return;
LibJS: Bring ArrayCreate and ArrayConstructor closer to spec Specifically, this now explicitly takes the length, adds missing exceptions checks to calls with user-supplied lengths, takes and uses the prototype argument, and fixes some spec non-conformance in ArrayConstructor and its native functions around the use of ArrayCreate
2021-07-04 01:36:44 +03:00
auto array = Array::create(global_object, 0);
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
size_t index = 0;
while (true) {
auto iterator_result = iterator_next(*iterator);
if (!iterator_result)
return;
auto complete = iterator_complete(global_object, *iterator_result);
if (vm.exception())
return;
if (complete) {
interpreter.accumulator() = array;
return;
}
auto value = iterator_value(global_object, *iterator_result);
if (vm.exception())
return;
array->put(index, value);
index++;
}
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void NewString::execute_impl(Bytecode::Interpreter& interpreter) 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: 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
interpreter.accumulator() = js_string(interpreter.vm(), interpreter.current_executable().get_string(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: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void NewObject::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 20:30:23 +02:00
{
LibJS: Replace Object's create_empty() with create() taking a prototype This now matches the spec's OrdinaryObjectCreate() across the board: instead of implicitly setting the created object's prototype to %Object.prototype% and then in many cases setting it to a nullptr right away, it now has an 'Object* prototype' parameter with _no default value_. This makes the code easier to compare with the spec, very clear in terms of what prototype is being used as well as avoiding unnecessary shape transitions. Also fixes a couple of cases were we weren't setting the correct prototype. There's no reason to assume that the object would not be empty (as in having own properties), so let's follow our existing pattern of Type::create(...) and simply call it 'create'.
2021-06-16 20:52:30 +01:00
interpreter.accumulator() = Object::create(interpreter.global_object(), interpreter.global_object().object_prototype());
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: Add bytecode support for regexp literals
2021-06-19 17:17:40 -07:00
void NewRegExp::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto source = interpreter.current_executable().get_string(m_source_index);
auto flags = interpreter.current_executable().get_string(m_flags_index);
interpreter.accumulator() = RegExpObject::create(interpreter.global_object(), source, flags);
}
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
void CopyObjectExcludingProperties::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto* from_object = interpreter.reg(m_from_object).to_object(interpreter.global_object());
if (interpreter.vm().exception())
return;
auto* to_object = Object::create(interpreter.global_object(), interpreter.global_object().object_prototype());
HashTable<Value, ValueTraits> excluded_names;
for (size_t i = 0; i < m_excluded_names_count; ++i) {
excluded_names.set(interpreter.reg(m_excluded_names[i]));
if (interpreter.vm().exception())
return;
}
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
auto own_keys = from_object->internal_own_property_keys();
if (interpreter.vm().exception())
return;
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
for (auto& key : own_keys) {
if (!excluded_names.contains(key)) {
auto property_name = PropertyName(key.to_property_key(interpreter.global_object()));
auto property_value = from_object->get(property_name);
if (interpreter.vm().exception())
return;
LibJS: Add define_direct_property and remove the define_property helper This removes all usages of the non-standard define_property helper method and replaces all it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-06 02:15:08 +03:00
to_object->define_direct_property(property_name, property_value, JS::default_attributes);
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
}
}
interpreter.accumulator() = to_object;
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void ConcatString::execute_impl(Bytecode::Interpreter& interpreter) 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
{
interpreter.reg(m_lhs) = add(interpreter.global_object(), interpreter.reg(m_lhs), interpreter.accumulator());
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 20:30:23 +02:00
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void GetVariable::execute_impl(Bytecode::Interpreter& interpreter) 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: 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
interpreter.accumulator() = interpreter.vm().get_variable(interpreter.current_executable().get_string(m_identifier), interpreter.global_object());
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void SetVariable::execute_impl(Bytecode::Interpreter& interpreter) 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: 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
interpreter.vm().set_variable(interpreter.current_executable().get_string(m_identifier), interpreter.accumulator(), interpreter.global_object());
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void GetById::execute_impl(Bytecode::Interpreter& interpreter) 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: 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
if (auto* object = interpreter.accumulator().to_object(interpreter.global_object()))
LibJS: Remove unnecessary value_or() from get() Object::get() never returns an empty value anymore, as per the spec, so having a value_or() fallback is no longer needed.
2021-07-04 22:55:45 +01:00
interpreter.accumulator() = object->get(interpreter.current_executable().get_string(m_property));
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 21:03:53 +02:00
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void PutById::execute_impl(Bytecode::Interpreter& interpreter) 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
{
if (auto* object = interpreter.reg(m_base).to_object(interpreter.global_object()))
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
object->put(interpreter.current_executable().get_string(m_property), interpreter.accumulator());
LibJS: Add PutById bytecode instruction for object property assignment Note that this is only used for non-computed accesses. Computed access is not yet implemented. :^)
2021-06-04 20:47:07 +02:00
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void Jump::execute_impl(Bytecode::Interpreter& interpreter) const
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
interpreter.jump(*m_true_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: 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
void Jump::replace_references_impl(BasicBlock const& from, BasicBlock const& to)
{
if (m_true_target.has_value() && &m_true_target->block() == &from)
m_true_target = Label { to };
if (m_false_target.has_value() && &m_false_target->block() == &from)
m_false_target = Label { to };
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void JumpConditional::execute_impl(Bytecode::Interpreter& interpreter) const
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
VERIFY(m_true_target.has_value());
VERIFY(m_false_target.has_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
auto result = interpreter.accumulator();
LibJS: Convert values to boolean for JumpIfTrue/JumpIfFalse Value::as_bool() might fail if the underlying value isn't already a boolean value.
2021-06-07 22:53:33 +02:00
if (result.to_boolean())
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
interpreter.jump(m_true_target.value());
else
interpreter.jump(m_false_target.value());
LibJS: Generate bytecode for do...while statements :^) This was quite straightforward using the same label/jump machinery that we added for while statements. The main addition here is a new JumpIfTrue bytecode instruction.
2021-06-04 12:20:44 +02:00
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void JumpNullish::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +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
VERIFY(m_true_target.has_value());
VERIFY(m_false_target.has_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
auto result = interpreter.accumulator();
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
if (result.is_nullish())
interpreter.jump(m_true_target.value());
else
interpreter.jump(m_false_target.value());
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
void JumpUndefined::execute_impl(Bytecode::Interpreter& interpreter) const
{
VERIFY(m_true_target.has_value());
VERIFY(m_false_target.has_value());
auto result = interpreter.accumulator();
if (result.is_undefined())
interpreter.jump(m_true_target.value());
else
interpreter.jump(m_false_target.value());
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void Call::execute_impl(Bytecode::Interpreter& interpreter) const
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
{
auto callee = interpreter.reg(m_callee);
if (!callee.is_function()) {
TODO();
}
auto& function = callee.as_function();
auto this_value = interpreter.reg(m_this_value);
Value return_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
if (m_argument_count == 0 && m_type == CallType::Call) {
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
return_value = interpreter.vm().call(function, this_value);
} else {
MarkedValueList argument_values { interpreter.vm().heap() };
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
for (size_t i = 0; i < m_argument_count; ++i) {
argument_values.append(interpreter.reg(m_arguments[i]));
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
}
LibJS: 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
if (m_type == CallType::Call)
return_value = interpreter.vm().call(function, this_value, move(argument_values));
else
LibJS: Remove GlobalObject& argument from VM::construct() We can just get the global object from the constructor function.
2021-06-10 23:17:29 +02:00
return_value = interpreter.vm().construct(function, function, move(argument_values));
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: 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
interpreter.accumulator() = return_value;
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void NewFunction::execute_impl(Bytecode::Interpreter& interpreter) 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
{
auto& vm = interpreter.vm();
LibJS: Rename ScriptFunction => OrdinaryFunctionObject These are basically what the spec calls "ordinary function objects", so let's have the name reflect that. :^)
2021-06-27 22:15:58 +02:00
interpreter.accumulator() = OrdinaryFunctionObject::create(interpreter.global_object(), m_function_node.name(), m_function_node.body(), m_function_node.parameters(), m_function_node.function_length(), vm.lexical_environment(), m_function_node.kind(), m_function_node.is_strict_mode(), m_function_node.is_arrow_function());
LibJS: Add a new EnterScope bytecode instruction This is intended to perform the same duties as enter_scope() does in the AST tree-walk interpreter: - Hoisted function declaration processing - Hoisted variable declaration processing - ... maybe more This first cut only implements the function declaration processing.
2021-06-05 15:14:09 +02:00
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void Return::execute_impl(Bytecode::Interpreter& interpreter) 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: 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
interpreter.do_return(interpreter.accumulator().value_or(js_undefined()));
LibJS: Compile ScriptFunctions into bytecode and run them that way :^) If there's a current Bytecode::Interpreter in action, ScriptFunction will now compile itself into bytecode and execute in that context. This patch also adds the Return bytecode instruction so that we can actually return values from called functions. :^) Return values are propagated from callee to caller via the caller's $0 register. Bytecode::Interpreter now keeps a stack of register "windows". These are not very efficient, but it should be pretty straightforward to convert them to e.g a sliding register window architecture later on. This is pretty dang cool! :^)
2021-06-05 15:53:36 +02:00
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void Increment::execute_impl(Bytecode::Interpreter& interpreter) 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
{
auto old_value = interpreter.accumulator().to_numeric(interpreter.global_object());
if (interpreter.vm().exception())
return;
if (old_value.is_number())
interpreter.accumulator() = Value(old_value.as_double() + 1);
else
interpreter.accumulator() = js_bigint(interpreter.vm().heap(), old_value.as_bigint().big_integer().plus(Crypto::SignedBigInteger { 1 }));
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void Decrement::execute_impl(Bytecode::Interpreter& interpreter) 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
{
auto old_value = interpreter.accumulator().to_numeric(interpreter.global_object());
if (interpreter.vm().exception())
return;
if (old_value.is_number())
interpreter.accumulator() = Value(old_value.as_double() - 1);
else
interpreter.accumulator() = js_bigint(interpreter.vm().heap(), old_value.as_bigint().big_integer().minus(Crypto::SignedBigInteger { 1 }));
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void Throw::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Generate bytecode for throw statements
2021-06-09 18:18:56 +02:00
{
interpreter.vm().throw_exception(interpreter.global_object(), interpreter.accumulator());
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void EnterUnwindContext::execute_impl(Bytecode::Interpreter& interpreter) 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
{
interpreter.enter_unwind_context(m_handler_target, m_finalizer_target);
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
interpreter.jump(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
}
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
void EnterUnwindContext::replace_references_impl(BasicBlock const& from, BasicBlock const& to)
{
if (&m_entry_point.block() == &from)
m_entry_point = Label { to };
if (m_handler_target.has_value() && &m_handler_target->block() == &from)
m_handler_target = Label { to };
if (m_finalizer_target.has_value() && &m_finalizer_target->block() == &from)
m_finalizer_target = Label { to };
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void LeaveUnwindContext::execute_impl(Bytecode::Interpreter& interpreter) 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
{
interpreter.leave_unwind_context();
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void ContinuePendingUnwind::execute_impl(Bytecode::Interpreter& interpreter) 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
{
interpreter.continue_pending_unwind(m_resume_target);
}
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
void ContinuePendingUnwind::replace_references_impl(BasicBlock const& from, BasicBlock const& to)
{
if (&m_resume_target.block() == &from)
m_resume_target = Label { to };
}
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
void PushDeclarativeEnvironment::execute_impl(Bytecode::Interpreter& interpreter) 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
{
HashMap<FlyString, Variable> resolved_variables;
for (auto& it : m_variables)
resolved_variables.set(interpreter.current_executable().get_string(it.key), it.value);
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
auto* environment = interpreter.vm().heap().allocate<DeclarativeEnvironment>(interpreter.global_object(), move(resolved_variables), interpreter.vm().lexical_environment());
interpreter.vm().running_execution_context().lexical_environment = environment;
interpreter.vm().running_execution_context().variable_environment = environment;
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: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void Yield::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
{
auto yielded_value = interpreter.accumulator().value_or(js_undefined());
LibJS: Replace Object's create_empty() with create() taking a prototype This now matches the spec's OrdinaryObjectCreate() across the board: instead of implicitly setting the created object's prototype to %Object.prototype% and then in many cases setting it to a nullptr right away, it now has an 'Object* prototype' parameter with _no default value_. This makes the code easier to compare with the spec, very clear in terms of what prototype is being used as well as avoiding unnecessary shape transitions. Also fixes a couple of cases were we weren't setting the correct prototype. There's no reason to assume that the object would not be empty (as in having own properties), so let's follow our existing pattern of Type::create(...) and simply call it 'create'.
2021-06-16 20:52:30 +01:00
auto object = JS::Object::create(interpreter.global_object(), nullptr);
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
object->put("result", yielded_value);
if (m_continuation_label.has_value())
object->put("continuation", Value(static_cast<double>(reinterpret_cast<u64>(&m_continuation_label->block()))));
else
object->put("continuation", Value(0));
interpreter.do_return(object);
}
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
void Yield::replace_references_impl(BasicBlock const& from, BasicBlock const& to)
{
if (m_continuation_label.has_value() && &m_continuation_label->block() == &from)
m_continuation_label = Label { to };
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void GetByValue::execute_impl(Bytecode::Interpreter& interpreter) 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
{
if (auto* object = interpreter.reg(m_base).to_object(interpreter.global_object())) {
auto property_key = interpreter.accumulator().to_property_key(interpreter.global_object());
if (interpreter.vm().exception())
return;
LibJS: Remove unnecessary value_or() from get() Object::get() never returns an empty value anymore, as per the spec, so having a value_or() fallback is no longer needed.
2021-07-04 22:55:45 +01:00
interpreter.accumulator() = object->get(property_key);
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: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
void PutByValue::execute_impl(Bytecode::Interpreter& interpreter) 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
{
if (auto* object = interpreter.reg(m_base).to_object(interpreter.global_object())) {
auto property_key = interpreter.reg(m_property).to_property_key(interpreter.global_object());
if (interpreter.vm().exception())
return;
object->put(property_key, interpreter.accumulator());
}
}
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
void GetIterator::execute_impl(Bytecode::Interpreter& interpreter) const
{
interpreter.accumulator() = get_iterator(interpreter.global_object(), interpreter.accumulator());
}
void IteratorNext::execute_impl(Bytecode::Interpreter& interpreter) const
{
if (auto* object = interpreter.accumulator().to_object(interpreter.global_object()))
interpreter.accumulator() = iterator_next(*object);
}
void IteratorResultDone::execute_impl(Bytecode::Interpreter& interpreter) const
{
if (auto* iterator_result = interpreter.accumulator().to_object(interpreter.global_object()))
interpreter.accumulator() = Value(iterator_complete(interpreter.global_object(), *iterator_result));
}
void IteratorResultValue::execute_impl(Bytecode::Interpreter& interpreter) const
{
if (auto* iterator_result = interpreter.accumulator().to_object(interpreter.global_object()))
interpreter.accumulator() = iterator_value(interpreter.global_object(), *iterator_result);
}
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
void NewClass::execute_impl(Bytecode::Interpreter&) const
{
LibJS: Try to fix Clang build (NewClass::m_class_expression is unused)
2021-07-01 17:45:45 +02:00
(void)m_class_expression;
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
TODO();
}
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
String Load::to_string_impl(Bytecode::Executable const&) const
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
{
LibJS: Simplify the way we stringify bytecode instructions For instructions that only have a single operand, omit the operand name since it's implied anyway.
2021-06-09 11:06:11 +02:00
return String::formatted("Load {}", m_src);
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: 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
String LoadImmediate::to_string_impl(Bytecode::Executable const&) const
LibJS: Make sure that if expressions yield the correct value When evaluated as an expression "if (true) { 3 } else { 5 }" should yield 3. This updates the bytecode interpreter to make it so.
2021-06-07 22:05:09 +02:00
{
LibJS: Simplify the way we stringify bytecode instructions For instructions that only have a single operand, omit the operand name since it's implied anyway.
2021-06-09 11:06:11 +02:00
return String::formatted("LoadImmediate {}", 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
}
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
String Store::to_string_impl(Bytecode::Executable const&) const
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
{
LibJS: Simplify the way we stringify bytecode instructions For instructions that only have a single operand, omit the operand name since it's implied anyway.
2021-06-09 11:06:11 +02:00
return String::formatted("Store {}", 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
}
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
String NewBigInt::to_string_impl(Bytecode::Executable const&) const
LibJS: Implement bytecode generation for BigInts
2021-06-08 07:59:25 +02:00
{
LibCrypto: Replace from_base{2,8,10,16}() & to_base10 with from_base(N) This allows us to support parsing and serializing BigIntegers to and from any base N (such that 2 <= N <= 36).
2021-06-29 17:51:52 +03:00
return String::formatted("NewBigInt \"{}\"", m_bigint.to_base(10));
LibJS: Implement bytecode generation for BigInts
2021-06-08 07:59:25 +02:00
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
String NewArray::to_string_impl(Bytecode::Executable const&) const
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
{
StringBuilder builder;
builder.append("NewArray");
if (m_element_count != 0) {
LibJS: Simplify the way we stringify bytecode instructions For instructions that only have a single operand, omit the operand name since it's implied anyway.
2021-06-09 11:06:11 +02:00
builder.append(" [");
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
for (size_t i = 0; i < m_element_count; ++i) {
builder.appendff("{}", m_elements[i]);
if (i != m_element_count - 1)
builder.append(',');
}
builder.append(']');
}
return builder.to_string();
}
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
String IteratorToArray::to_string_impl(const Bytecode::Executable&) const
{
return "IteratorToArray";
}
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
String NewString::to_string_impl(Bytecode::Executable const& executable) 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: 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
return String::formatted("NewString {} (\"{}\")", m_string, executable.string_table->get(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: 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
String NewObject::to_string_impl(Bytecode::Executable const&) const
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 20:30:23 +02: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
return "NewObject";
}
LibJS: Add bytecode support for regexp literals
2021-06-19 17:17:40 -07:00
String NewRegExp::to_string_impl(Bytecode::Executable const& executable) const
{
return String::formatted("NewRegExp source:{} (\"{}\") flags:{} (\"{}\")", m_source_index, executable.get_string(m_source_index), m_flags_index, executable.get_string(m_flags_index));
}
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
String CopyObjectExcludingProperties::to_string_impl(const Bytecode::Executable&) const
{
StringBuilder builder;
builder.appendff("CopyObjectExcludingProperties from:{}", m_from_object);
if (m_excluded_names_count != 0) {
builder.append(" excluding:[");
for (size_t i = 0; i < m_excluded_names_count; ++i) {
builder.appendff("{}", m_excluded_names[i]);
if (i != m_excluded_names_count - 1)
builder.append(',');
}
builder.append(']');
}
return builder.to_string();
}
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
String ConcatString::to_string_impl(Bytecode::Executable const&) const
LibJS: Introduce an accumulator register to Bytecode::Interpreter This commit introduces the concept of an accumulator register to LibJS's bytecode interpreter. The accumulator register is always register 0, and most simple instructions use it for reading and writing. Not only does this slim down the AST, but it also simplifies a lot of the code. For example, the generate_bytecode methods no longer need to return an Optional<Register>, as any opcode which has a "return" value will always put it into the accumulator. This also renames the old Op::Load to Op::LoadImmediate, and uses Op::Load to load from a register into the accumulator. There is also an Op::Store to put the value in the accumulator into another register.
2021-06-07 20:58:36 -07:00
{
LibJS: Simplify the way we stringify bytecode instructions For instructions that only have a single operand, omit the operand name since it's implied anyway.
2021-06-09 11:06:11 +02:00
return String::formatted("ConcatString {}", m_lhs);
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 20:30:23 +02:00
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
String GetVariable::to_string_impl(Bytecode::Executable const& executable) 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: 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
return String::formatted("GetVariable {} ({})", m_identifier, executable.string_table->get(m_identifier));
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
}
LibJS: 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
String SetVariable::to_string_impl(Bytecode::Executable const& executable) 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: 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
return String::formatted("SetVariable {} ({})", m_identifier, executable.string_table->get(m_identifier));
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
}
LibJS: 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
String PutById::to_string_impl(Bytecode::Executable const& executable) 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
{
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
return String::formatted("PutById base:{}, property:{} ({})", m_base, m_property, executable.string_table->get(m_property));
LibJS: Add PutById bytecode instruction for object property assignment Note that this is only used for non-computed accesses. Computed access is not yet implemented. :^)
2021-06-04 20:47:07 +02:00
}
LibJS: 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
String GetById::to_string_impl(Bytecode::Executable const& executable) 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: 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
return String::formatted("GetById {} ({})", m_property, executable.string_table->get(m_property));
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 21:03:53 +02:00
}
LibJS: 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
String Jump::to_string_impl(Bytecode::Executable const&) const
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
if (m_true_target.has_value())
return String::formatted("Jump {}", *m_true_target);
return String::formatted("Jump <empty>");
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
String JumpConditional::to_string_impl(Bytecode::Executable const&) const
LibJS: Generate bytecode for do...while statements :^) This was quite straightforward using the same label/jump machinery that we added for while statements. The main addition here is a new JumpIfTrue bytecode instruction.
2021-06-04 12:20:44 +02:00
{
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 06:49:58 +04:30
auto true_string = m_true_target.has_value() ? String::formatted("{}", *m_true_target) : "<empty>";
auto false_string = m_false_target.has_value() ? String::formatted("{}", *m_false_target) : "<empty>";
return String::formatted("JumpConditional true:{} false:{}", true_string, false_string);
LibJS: Generate bytecode for do...while statements :^) This was quite straightforward using the same label/jump machinery that we added for while statements. The main addition here is a new JumpIfTrue bytecode instruction.
2021-06-04 12:20:44 +02:00
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
String JumpNullish::to_string_impl(Bytecode::Executable const&) const
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +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
auto true_string = m_true_target.has_value() ? String::formatted("{}", *m_true_target) : "<empty>";
auto false_string = m_false_target.has_value() ? String::formatted("{}", *m_false_target) : "<empty>";
return String::formatted("JumpNullish null:{} nonnull:{}", true_string, false_string);
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
String JumpUndefined::to_string_impl(Bytecode::Executable const&) const
{
auto true_string = m_true_target.has_value() ? String::formatted("{}", *m_true_target) : "<empty>";
auto false_string = m_false_target.has_value() ? String::formatted("{}", *m_false_target) : "<empty>";
return String::formatted("JumpUndefined undefined:{} not undefined:{}", true_string, false_string);
}
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
String Call::to_string_impl(Bytecode::Executable const&) const
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
{
StringBuilder builder;
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
builder.appendff("Call callee:{}, this:{}", m_callee, m_this_value);
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
if (m_argument_count != 0) {
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
builder.append(", arguments:[");
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
for (size_t i = 0; i < m_argument_count; ++i) {
LibJS: Support basic function calls in the bytecode world :^) This patch adds the Call bytecode instruction which is emitted for the CallExpression AST node. It's pretty barebones and doesn't handle 'this' values properly, etc. But it can perform basic function calls! :^) Note that the called function will *not* execute as bytecode, but will simply fall back into the old codepath and use the AST interpreter.
2021-06-05 15:15:30 +02:00
builder.appendff("{}", m_arguments[i]);
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
if (i != m_argument_count - 1)
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
builder.append(',');
}
builder.append(']');
}
return builder.to_string();
}
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
String NewFunction::to_string_impl(Bytecode::Executable const&) const
LibJS: Add a new EnterScope bytecode instruction This is intended to perform the same duties as enter_scope() does in the AST tree-walk interpreter: - Hoisted function declaration processing - Hoisted variable declaration processing - ... maybe more This first cut only implements the function declaration processing.
2021-06-05 15:14:09 +02:00
{
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
return "NewFunction";
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: 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
String NewClass::to_string_impl(Bytecode::Executable const&) const
{
return "NewClass";
}
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
String Return::to_string_impl(Bytecode::Executable const&) const
LibJS: Compile ScriptFunctions into bytecode and run them that way :^) If there's a current Bytecode::Interpreter in action, ScriptFunction will now compile itself into bytecode and execute in that context. This patch also adds the Return bytecode instruction so that we can actually return values from called functions. :^) Return values are propagated from callee to caller via the caller's $0 register. Bytecode::Interpreter now keeps a stack of register "windows". These are not very efficient, but it should be pretty straightforward to convert them to e.g a sliding register window architecture later on. This is pretty dang cool! :^)
2021-06-05 15:53:36 +02:00
{
return "Return";
}
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
String Increment::to_string_impl(Bytecode::Executable const&) const
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
{
return "Increment";
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
String Decrement::to_string_impl(Bytecode::Executable const&) const
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
{
return "Decrement";
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
String Throw::to_string_impl(Bytecode::Executable const&) const
LibJS: Generate bytecode for throw statements
2021-06-09 18:18:56 +02:00
{
return "Throw";
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
String EnterUnwindContext::to_string_impl(Bytecode::Executable const&) const
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
{
auto handler_string = m_handler_target.has_value() ? String::formatted("{}", *m_handler_target) : "<empty>";
auto finalizer_string = m_finalizer_target.has_value() ? String::formatted("{}", *m_finalizer_target) : "<empty>";
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
return String::formatted("EnterUnwindContext handler:{} finalizer:{} entry:{}", handler_string, finalizer_string, 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
}
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
String LeaveUnwindContext::to_string_impl(Bytecode::Executable const&) const
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
{
return "LeaveUnwindContext";
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
String ContinuePendingUnwind::to_string_impl(Bytecode::Executable const&) const
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
{
return String::formatted("ContinuePendingUnwind resume:{}", m_resume_target);
}
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
String PushDeclarativeEnvironment::to_string_impl(const Bytecode::Executable& executable) 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
{
StringBuilder builder;
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
builder.append("PushDeclarativeEnvironment");
LibJS: Generate bytecode for entering nested lexical environments This adds a new PushLexicalEnvironment instruction that creates a new LexicalEnvironment and pushes it on the VM's scope stack. There is no corresponding PopLexicalEnvironment instruction yet, so this will behave incorrectly with let/const scopes for example.
2021-06-10 22:12:21 +02:00
if (!m_variables.is_empty()) {
builder.append(" {");
Vector<String> names;
for (auto& it : m_variables)
names.append(executable.get_string(it.key));
builder.join(", ", names);
builder.append("}");
}
return builder.to_string();
}
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
String Yield::to_string_impl(Bytecode::Executable const&) const
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
{
if (m_continuation_label.has_value())
return String::formatted("Yield continuation:@{}", m_continuation_label->block().name());
return String::formatted("Yield return");
}
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
String GetByValue::to_string_impl(const Bytecode::Executable&) 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
{
return String::formatted("GetByValue base:{}", m_base);
}
LibJS: Rename the overridden Instruction methods to foo_impl These are pretty hairy if someone forgets to override one, as the catchall function in Instruction will keep calling itself over and over again, leading to really hard-to-debug situations.
2021-06-15 18:08:12 +04:30
String PutByValue::to_string_impl(const Bytecode::Executable&) 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
{
return String::formatted("PutByValue base:{}, property:{}", m_base, m_property);
}
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
String GetIterator::to_string_impl(Executable const&) const
{
return "GetIterator";
}
String IteratorNext::to_string_impl(Executable const&) const
{
return "IteratorNext";
}
String IteratorResultDone::to_string_impl(Executable const&) const
{
return "IteratorResultDone";
}
String IteratorResultValue::to_string_impl(Executable const&) const
{
return "IteratorResultValue";
}
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
}
Reference in a new issue Copy permalink