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

879 lines
34 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: Implement proper Iterator records Instead of using plain objects as Iterator records, causes confusion about the object itself actually being its [[Iterator]] slot, and requires non-standard type conversion shenanigans fpr the [[NextValue]] and [[Done]] internal slots, implement a proper Iterator record struct and use it throughout. Also annotate the remaining Iterator AOs with spec comments while we're here.
2022-01-09 19:12:24 +01:00
* Copyright (c) 2021-2022, 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: 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: Remove vm.construct and it's usages
2021-10-23 01:49:10 +03:00
#include <LibJS/Runtime/AbstractOperations.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>
LibJS: Rename OrdinaryFunctionObject to ECMAScriptFunctionObject The old name is the result of the perhaps somewhat confusingly named abstract operation OrdinaryFunctionCreate(), which creates an "ordinary object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an "exotic object" (https://tc39.es/ecma262/#exotic-object). However, the term "Ordinary Function" is not used anywhere in the spec, instead the created object is referred to as an "ECMAScript Function Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so let's call it that. The "ordinary" vs. "exotic" distinction is important because there are also "Built-in Function Objects", which can be either implemented as ordinary ECMAScript function objects, or as exotic objects (our NativeFunction). More work needs to be done to move a lot of infrastructure to ECMAScriptFunctionObject in order to make FunctionObject nothing more than an interface for objects that implement [[Call]] and optionally [[Construct]].
2021-09-24 22:40:38 +02:00
#include <LibJS/Runtime/ECMAScriptFunctionObject.h>
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
#include <LibJS/Runtime/Environment.h>
LibJS: 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 proper Iterator records Instead of using plain objects as Iterator records, causes confusion about the object itself actually being its [[Iterator]] slot, and requires non-standard type conversion shenanigans fpr the [[NextValue]] and [[Done]] internal slots, implement a proper Iterator record struct and use it throughout. Also annotate the remaining Iterator AOs with spec comments while we're here.
2022-01-09 19:12:24 +01:00
#include <LibJS/Runtime/Iterator.h>
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
#include <LibJS/Runtime/IteratorOperations.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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
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: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
static ThrowCompletionOr<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: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
return Value(!TRY(is_loosely_equal(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: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
static ThrowCompletionOr<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: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
return Value(TRY(is_loosely_equal(global_object, src1, src2)));
LibJS: Add Sub bytecode instruction (subtract values)
2021-06-03 18:32:33 +02:00
}
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
static ThrowCompletionOr<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: Rename strict_eq() to is_strictly_equal() This got turned into a proper AO with a new name recently. See: https://github.com/tc39/ecma262/commit/19d7ca4
2021-09-23 23:43:28 +02:00
return Value(!is_strictly_equal(src1, src2));
LibJS: Add bytecode instructions for multiplication and division
2021-06-07 19:17:20 +02:00
}
LibJS: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
static ThrowCompletionOr<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: Rename strict_eq() to is_strictly_equal() This got turned into a proper AO with a new name recently. See: https://github.com/tc39/ecma262/commit/19d7ca4
2021-09-23 23:43:28 +02:00
return Value(is_strictly_equal(src1, src2));
LibJS: Add bytecode instructions for multiplication and division
2021-06-07 19:17:20 +02:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
#define JS_DEFINE_COMMON_BINARY_OP(OpTitleCase, op_snake_case) \
ThrowCompletionOr<void> OpTitleCase::execute_impl(Bytecode::Interpreter& interpreter) const \
{ \
auto lhs = interpreter.reg(m_lhs_reg); \
auto rhs = interpreter.accumulator(); \
interpreter.accumulator() = TRY(op_snake_case(interpreter.global_object(), lhs, rhs)); \
return {}; \
} \
String OpTitleCase::to_string_impl(Bytecode::Executable const&) const \
{ \
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: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
static ThrowCompletionOr<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: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
static ThrowCompletionOr<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: Convert Value operator AOs to ThrowCompletionOr
2021-10-19 00:13:29 +03:00
return Value(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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
#define JS_DEFINE_COMMON_UNARY_OP(OpTitleCase, op_snake_case) \
ThrowCompletionOr<void> OpTitleCase::execute_impl(Bytecode::Interpreter& interpreter) const \
{ \
interpreter.accumulator() = TRY(op_snake_case(interpreter.global_object(), interpreter.accumulator())); \
return {}; \
} \
String OpTitleCase::to_string_impl(Bytecode::Executable const&) const \
{ \
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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
LibJS: Implement bytecode generation for BigInts
2021-06-08 07:59:25 +02:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
LibJS: Generate bytecode for array expressions
2021-06-08 23:06:52 +02:00
}
LibJS: Implement proper Iterator records Instead of using plain objects as Iterator records, causes confusion about the object itself actually being its [[Iterator]] slot, and requires non-standard type conversion shenanigans fpr the [[NextValue]] and [[Done]] internal slots, implement a proper Iterator record struct and use it throughout. Also annotate the remaining Iterator AOs with spec comments while we're here.
2022-01-09 19:12:24 +01:00
// FIXME: Since the accumulator is a Value, we store an object there and have to convert back and forth between that an Iterator records. Not great.
// Make sure to put this into the accumulator before the iterator object disappears from the stack to prevent the members from being GC'd.
static Object* iterator_to_object(GlobalObject& global_object, Iterator iterator)
{
auto& vm = global_object.vm();
auto* object = Object::create(global_object, nullptr);
object->define_direct_property(vm.names.iterator, iterator.iterator, 0);
object->define_direct_property(vm.names.next, iterator.next_method, 0);
object->define_direct_property(vm.names.done, Value(iterator.done), 0);
return object;
}
static Iterator object_to_iterator(GlobalObject& global_object, Object& object)
{
auto& vm = global_object.vm();
return Iterator {
.iterator = &MUST(object.get(vm.names.iterator)).as_object(),
.next_method = MUST(object.get(vm.names.next)),
.done = MUST(object.get(vm.names.done)).as_bool()
};
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> IteratorToArray::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
{
auto& global_object = interpreter.global_object();
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto iterator_object = TRY(interpreter.accumulator().to_object(global_object));
auto iterator = object_to_iterator(global_object, *iterator_object);
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
LibJS: Convert Array AOs to ThrowCompletionOr
2021-10-22 01:34:06 +03:00
auto* array = MUST(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) {
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto* iterator_result = TRY(iterator_next(global_object, iterator));
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto complete = TRY(iterator_complete(global_object, *iterator_result));
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
if (complete) {
interpreter.accumulator() = array;
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto value = TRY(iterator_value(global_object, *iterator_result));
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
LibJS: Convert create_data_property_or_throw() to ThrowCompletionOr
2021-10-03 01:18:46 +01:00
MUST(array->create_data_property_or_throw(index, value));
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
index++;
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
LibJS: Support array rest elements in the bytecode interpreter
2021-06-13 14:06:26 -07:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> NewRegExp::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Add bytecode support for regexp literals
2021-06-19 17:17:40 -07:00
{
auto source = interpreter.current_executable().get_string(m_source_index);
auto flags = interpreter.current_executable().get_string(m_flags_index);
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
interpreter.accumulator() = TRY(regexp_create(interpreter.global_object(), js_string(interpreter.vm(), source), js_string(interpreter.vm(), flags)));
return {};
LibJS: Add bytecode support for regexp literals
2021-06-19 17:17:40 -07:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> CopyObjectExcludingProperties::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
{
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto* from_object = TRY(interpreter.reg(m_from_object).to_object(interpreter.global_object()));
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
auto* to_object = Object::create(interpreter.global_object(), interpreter.global_object().object_prototype());
HashTable<Value, ValueTraits> excluded_names;
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
for (size_t i = 0; i < m_excluded_names_count; ++i)
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
excluded_names.set(interpreter.reg(m_excluded_names[i]));
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto own_keys = TRY(from_object->internal_own_property_keys());
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)) {
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto property_key = TRY(key.to_property_key(interpreter.global_object()));
auto property_value = TRY(from_object->get(property_key));
Everywhere: Rename JS::PropertyKey variables from property_{name => key} PropertyKey used to be called PropertyName, but got renamed. Let's update all the variables of this type as well.
2022-02-06 15:59:04 +00:00
to_object->define_direct_property(property_key, 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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
LibJS: Support object rest elements in the bytecode interpreter
2021-06-13 15:30:32 -07:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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
{
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
interpreter.reg(m_lhs) = TRY(add(interpreter.global_object(), interpreter.reg(m_lhs), interpreter.accumulator()));
return {};
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 20:30:23 +02:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto get_reference = [&]() -> ThrowCompletionOr<Reference> {
LibJS: Add the "fast non-local access" optimization to the bytecode VM The GetVariable bytecode op now caches environment coordinates for fast cross-scope variable lookup.
2021-10-24 15:36:24 +02:00
auto const& string = interpreter.current_executable().get_identifier(m_identifier);
if (m_cached_environment_coordinate.has_value()) {
auto* environment = interpreter.vm().running_execution_context().lexical_environment;
for (size_t i = 0; i < m_cached_environment_coordinate->hops; ++i)
environment = environment->outer_environment();
VERIFY(environment);
VERIFY(environment->is_declarative_environment());
if (!environment->is_permanently_screwed_by_eval()) {
return Reference { *environment, string, interpreter.vm().in_strict_mode(), m_cached_environment_coordinate };
}
m_cached_environment_coordinate = {};
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto reference = TRY(interpreter.vm().resolve_binding(string));
LibJS: Add the "fast non-local access" optimization to the bytecode VM The GetVariable bytecode op now caches environment coordinates for fast cross-scope variable lookup.
2021-10-24 15:36:24 +02:00
if (reference.environment_coordinate().has_value())
m_cached_environment_coordinate = reference.environment_coordinate();
return reference;
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
};
auto reference = TRY(get_reference());
interpreter.accumulator() = TRY(reference.get_value(interpreter.global_object()));
return {};
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: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
ThrowCompletionOr<void> CreateEnvironment::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto make_and_swap_envs = [&](auto*& old_environment) {
Environment* environment = new_declarative_environment(*old_environment);
swap(old_environment, environment);
return environment;
};
if (m_mode == EnvironmentMode::Lexical)
interpreter.saved_lexical_environment_stack().append(make_and_swap_envs(interpreter.vm().running_execution_context().lexical_environment));
else if (m_mode == EnvironmentMode::Var)
interpreter.saved_variable_environment_stack().append(make_and_swap_envs(interpreter.vm().running_execution_context().variable_environment));
return {};
}
ThrowCompletionOr<void> CreateVariable::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: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
auto& vm = interpreter.vm();
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
auto const& name = interpreter.current_executable().get_identifier(m_identifier);
LibJS: Make scoping follow the spec Before this we used an ad-hoc combination of references and 'variables' stored in a hashmap. This worked in most cases but is not spec like. Additionally hoisting, dynamically naming functions and scope analysis was not done properly. This patch fixes all of that by: - Implement BindingInitialization for destructuring assignment. - Implementing a new ScopePusher which tracks the lexical and var scoped declarations. This hoists functions to the top level if no lexical declaration name overlaps. Furthermore we do checking of redeclarations in the ScopePusher now requiring less checks all over the place. - Add methods for parsing the directives and statement lists instead of having that code duplicated in multiple places. This allows declarations to pushed to the appropriate scope more easily. - Remove the non spec way of storing 'variables' in DeclarativeEnvironment and make Reference follow the spec instead of checking both the bindings and 'variables'. - Remove all scoping related things from the Interpreter. And instead use environments as specified by the spec. This also includes fixing that NativeFunctions did not produce a valid FunctionEnvironment which could cause issues with callbacks and eval. All FunctionObjects now have a valid NewFunctionEnvironment implementation. - Remove execute_statements from Interpreter and instead use ASTNode::execute everywhere this simplifies AST.cpp as you no longer need to worry about which method to call. - Make ScopeNodes setup their own environment. This uses four different methods specified by the spec {Block, Function, Eval, Global}DeclarationInstantiation with the annexB extensions. - Implement and use NamedEvaluation where specified. Additionally there are fixes to things exposed by these changes to eval, {for, for-in, for-of} loops and assignment. Finally it also fixes some tests in test-js which where passing before but not now that we have correct behavior :^).
2021-09-22 12:44:56 +02:00
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
if (m_mode == EnvironmentMode::Lexical) {
// Note: This is papering over an issue where "FunctionDeclarationInstantiation" creates these bindings for us.
// Instead of crashing in there, we'll just raise an exception here.
if (TRY(vm.lexical_environment()->has_binding(name)))
return vm.throw_completion<InternalError>(interpreter.global_object(), String::formatted("Lexical environment already has binding '{}'", name));
if (m_is_immutable)
vm.lexical_environment()->create_immutable_binding(interpreter.global_object(), name, vm.in_strict_mode());
else
vm.lexical_environment()->create_mutable_binding(interpreter.global_object(), name, vm.in_strict_mode());
} else {
if (m_is_immutable)
vm.variable_environment()->create_immutable_binding(interpreter.global_object(), name, vm.in_strict_mode());
else
vm.variable_environment()->create_mutable_binding(interpreter.global_object(), name, vm.in_strict_mode());
}
return {};
}
ThrowCompletionOr<void> SetVariable::execute_impl(Bytecode::Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
auto const& name = interpreter.current_executable().get_identifier(m_identifier);
auto environment = m_mode == EnvironmentMode::Lexical ? vm.running_execution_context().lexical_environment : vm.running_execution_context().variable_environment;
auto reference = TRY(vm.resolve_binding(name, environment));
switch (m_initialization_mode) {
case InitializationMode::Initialize:
TRY(reference.initialize_referenced_binding(interpreter.global_object(), interpreter.accumulator()));
break;
case InitializationMode::Set:
TRY(reference.put_value(interpreter.global_object(), interpreter.accumulator()));
break;
case InitializationMode::InitializeOrSet:
VERIFY(reference.is_environment_reference());
VERIFY(reference.base_environment().is_declarative_environment());
TRY(static_cast<DeclarativeEnvironment&>(reference.base_environment()).initialize_or_set_mutable_binding(interpreter.global_object(), name, interpreter.accumulator()));
break;
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto* object = TRY(interpreter.accumulator().to_object(interpreter.global_object()));
interpreter.accumulator() = TRY(object->get(interpreter.current_executable().get_identifier(m_property)));
return {};
LibJS: Add GetById bytecode instruction for object property retrieval Same as PutById but in the other direction. :^)
2021-06-04 21:03:53 +02:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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
{
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto* object = TRY(interpreter.reg(m_base).to_object(interpreter.global_object()));
TRY(object->set(interpreter.current_executable().get_identifier(m_property), interpreter.accumulator(), Object::ShouldThrowExceptions::Yes));
return {};
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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> ResolveThisBinding::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Implement 'this' in the bytecode VM ThisExpression now emits a "ResolveThisBinding" bytecode op, which simply loads the VM's current 'this' binding into the accumulator.
2021-10-24 14:43:00 +02:00
{
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
interpreter.accumulator() = TRY(interpreter.vm().resolve_this_binding(interpreter.global_object()));
return {};
LibJS: Implement 'this' in the bytecode VM ThisExpression now emits a "ResolveThisBinding" bytecode op, which simply loads the VM's current 'this' binding into the accumulator.
2021-10-24 14:43:00 +02:00
}
LibJS: 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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
LibJS: Generate bytecode for do...while statements :^) This was quite straightforward using the same label/jump machinery that we added for while statements. The main addition here is a new JumpIfTrue bytecode instruction.
2021-06-04 12:20:44 +02:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
LibJS: Implement bytecode ops for logical expressions
2021-06-08 02:18:47 +02:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> JumpUndefined::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Add JumpUndefined bytecode
2021-06-13 12:24:40 -07:00
{
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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
LibJS: Add JumpUndefined bytecode
2021-06-13 12:24:40 -07:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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);
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
if (!callee.is_function())
return interpreter.vm().throw_completion<TypeError>(interpreter.global_object(), ErrorType::IsNotA, callee.to_string_without_side_effects(), "function"sv);
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& function = callee.as_function();
auto this_value = interpreter.reg(m_this_value);
LibJS: Propagate abrupt completions in Bytecode::Op::Call This was not handling the nullary call case correctly, remove the whole nullary check as there's nothing particularly expensive in the catch-all case anyway.
2022-03-13 11:48:50 +03:30
MarkedVector<Value> argument_values { interpreter.vm().heap() };
for (size_t i = 0; i < m_argument_count; ++i)
argument_values.append(interpreter.reg(m_arguments[i]));
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
LibJS: Propagate abrupt completions in Bytecode::Op::Call This was not handling the nullary call case correctly, remove the whole nullary check as there's nothing particularly expensive in the catch-all case anyway.
2022-03-13 11:48:50 +03:30
Value return_value;
if (m_type == CallType::Call)
return_value = TRY(call(interpreter.global_object(), function, this_value, move(argument_values)));
else
return_value = TRY(construct(interpreter.global_object(), 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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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: Pass source text to ECMAScriptFunctionObject::create()
2022-01-18 23:47:11 +00:00
interpreter.accumulator() = ECMAScriptFunctionObject::create(interpreter.global_object(), m_function_node.name(), m_function_node.source_text(), m_function_node.body(), m_function_node.parameters(), m_function_node.function_length(), vm.lexical_environment(), vm.running_execution_context().private_environment, m_function_node.kind(), m_function_node.is_strict_mode(), m_function_node.might_need_arguments_object(), m_function_node.is_arrow_function());
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
LibJS: Add a new EnterScope bytecode instruction This is intended to perform the same duties as enter_scope() does in the AST tree-walk interpreter: - Hoisted function declaration processing - Hoisted variable declaration processing - ... maybe more This first cut only implements the function declaration processing.
2021-06-05 15:14:09 +02:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
LibJS: Compile ScriptFunctions into bytecode and run them that way :^) If there's a current Bytecode::Interpreter in action, ScriptFunction will now compile itself into bytecode and execute in that context. This patch also adds the Return bytecode instruction so that we can actually return values from called functions. :^) Return values are propagated from callee to caller via the caller's $0 register. Bytecode::Interpreter now keeps a stack of register "windows". These are not very efficient, but it should be pretty straightforward to convert them to e.g a sliding register window architecture later on. This is pretty dang cool! :^)
2021-06-05 15:53:36 +02:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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
{
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto old_value = TRY(interpreter.accumulator().to_numeric(interpreter.global_object()));
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
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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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
{
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto old_value = TRY(interpreter.accumulator().to_numeric(interpreter.global_object()));
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
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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
LibJS: Implement bytecode generation for UpdateExpression :^) Added Increment and Decrement bytecode ops to support this. Postfix updates use a temporary register to preserve the original value. Note that this patch only implements Identifier updates. Member expression updates are a TODO.
2021-06-09 11:40:38 +02:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> Throw::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Generate bytecode for throw statements
2021-06-09 18:18:56 +02:00
{
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return throw_completion(interpreter.accumulator());
LibJS: Generate bytecode for throw statements
2021-06-09 18:18:56 +02:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> FinishUnwind::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Fix codegen for nodes after try statements without 'finally' Previously we were just dropping them on the ground :P
2021-11-10 22:22:26 +03:30
{
interpreter.leave_unwind_context();
interpreter.jump(m_next_target);
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
LibJS: Fix codegen for nodes after try statements without 'finally' Previously we were just dropping them on the ground :P
2021-11-10 22:22:26 +03:30
}
void FinishUnwind::replace_references_impl(BasicBlock const& from, BasicBlock const& to)
{
if (&m_next_target.block() == &from)
m_next_target = Label { to };
}
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
ThrowCompletionOr<void> LeaveEnvironment::execute_impl(Bytecode::Interpreter& interpreter) const
{
if (m_mode == EnvironmentMode::Lexical)
interpreter.vm().running_execution_context().lexical_environment = interpreter.saved_lexical_environment_stack().take_last();
if (m_mode == EnvironmentMode::Var)
interpreter.vm().running_execution_context().variable_environment = interpreter.saved_variable_environment_stack().take_last();
return {};
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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
{
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return interpreter.continue_pending_unwind(m_resume_target);
LibJS: Implement bytecode generation for try..catch..finally EnterUnwindContext pushes an unwind context (exception handler and/or finalizer) onto a stack. LeaveUnwindContext pops the unwind context from that stack. Upon return to the interpreter loop we check whether the VM has an exception pending. If no unwind context is available we return from the loop. If an exception handler is available we clear the VM's exception, put the exception value into the accumulator register, clear the unwind context's handler and jump to the handler. If no handler is available but a finalizer is available we save the exception value + metadata (for later use by ContinuePendingUnwind), clear the VM's exception, pop the unwind context and jump to the finalizer. ContinuePendingUnwind checks whether a saved exception is available. If no saved exception is available it jumps to the resume label. Otherwise it stores the exception into the VM. The Jump after LeaveUnwindContext could be integrated into the LeaveUnwindContext instruction. I've kept them separate for now to make the bytecode more readable. > try { 1; throw "x" } catch (e) { 2 } finally { 3 }; 4 1: [ 0] EnterScope [ 10] EnterUnwindContext handler:@4 finalizer:@3 [ 38] EnterScope [ 48] LoadImmediate 1 [ 60] NewString 1 ("x") [ 70] Throw <for non-terminated blocks: insert LeaveUnwindContext + Jump @3 here> 2: [ 0] LoadImmediate 4 3: [ 0] EnterScope [ 10] LoadImmediate 3 [ 28] ContinuePendingUnwind resume:@2 4: [ 0] SetVariable 0 (e) [ 10] EnterScope [ 20] LoadImmediate 2 [ 38] LeaveUnwindContext [ 3c] Jump @3 String Table: 0: e 1: x
2021-06-10 15:04:38 +02:00
}
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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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
{
LibJS: Remove unnecessary GlobalObject pointer from Environment As it turns out, we didn't actually need this pointer. :^)
2022-01-31 13:00:02 +01:00
auto* environment = interpreter.vm().heap().allocate_without_global_object<DeclarativeEnvironment>(interpreter.vm().lexical_environment());
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
interpreter.vm().running_execution_context().lexical_environment = environment;
interpreter.vm().running_execution_context().variable_environment = environment;
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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: Remove the non-standard put helper and replace it's usages This removes all usages of the non-standard put helper method and replaces all of it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-06 01:15:50 +03:00
object->define_direct_property("result", yielded_value, JS::default_attributes);
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
if (m_continuation_label.has_value())
LibJS: Remove the non-standard put helper and replace it's usages This removes all usages of the non-standard put helper method and replaces all of it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-06 01:15:50 +03:00
object->define_direct_property("continuation", Value(static_cast<double>(reinterpret_cast<u64>(&m_continuation_label->block()))), JS::default_attributes);
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
else
LibJS: Remove the non-standard put helper and replace it's usages This removes all usages of the non-standard put helper method and replaces all of it's usages with the specification required alternative or with define_direct_property where appropriate.
2021-07-06 01:15:50 +03:00
object->define_direct_property("continuation", Value(0), JS::default_attributes);
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
interpreter.do_return(object);
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
LibJS: Implement generator functions (only in bytecode mode)
2021-06-11 01:38:30 +04:30
}
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: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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
{
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto* object = TRY(interpreter.reg(m_base).to_object(interpreter.global_object()));
auto property_key = TRY(interpreter.accumulator().to_property_key(interpreter.global_object()));
interpreter.accumulator() = TRY(object->get(property_key));
return {};
LibJS: Basic bytecode support for computed member expressions Expressions like foo[1 + 2] now work, and you can assign to them as well! :^)
2021-06-11 00:35:25 +02:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> 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
{
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto* object = TRY(interpreter.reg(m_base).to_object(interpreter.global_object()));
auto property_key = TRY(interpreter.reg(m_property).to_property_key(interpreter.global_object()));
TRY(object->set(property_key, interpreter.accumulator(), Object::ShouldThrowExceptions::Yes));
return {};
LibJS: Basic bytecode support for computed member expressions Expressions like foo[1 + 2] now work, and you can assign to them as well! :^)
2021-06-11 00:35:25 +02:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> GetIterator::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
{
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto iterator = TRY(get_iterator(interpreter.global_object(), interpreter.accumulator()));
interpreter.accumulator() = iterator_to_object(interpreter.global_object(), iterator);
return {};
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> IteratorNext::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
{
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto* iterator_object = TRY(interpreter.accumulator().to_object(interpreter.global_object()));
auto iterator = object_to_iterator(interpreter.global_object(), *iterator_object);
LibJS: Convert IteratorNext AO to ThrowCompletionOr
2021-10-20 08:44:30 -04:00
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
interpreter.accumulator() = TRY(iterator_next(interpreter.global_object(), iterator));
return {};
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> IteratorResultDone::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
{
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto* iterator_result = TRY(interpreter.accumulator().to_object(interpreter.global_object()));
LibJS: Convert IteratorComplete AO to ThrowCompletionOr
2021-10-20 09:00:37 -04:00
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto complete = TRY(iterator_complete(interpreter.global_object(), *iterator_result));
LibJS: Convert IteratorComplete AO to ThrowCompletionOr
2021-10-20 09:00:37 -04:00
interpreter.accumulator() = Value(complete);
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
return {};
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
}
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
ThrowCompletionOr<void> IteratorResultValue::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
{
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
auto* iterator_result = TRY(interpreter.accumulator().to_object(interpreter.global_object()));
LibJS: Convert IteratorValue AO to ThrowCompletionOr
2021-10-20 09:05:52 -04:00
LibJS: Convert Instruction::execute in bytecode to ThrowCompletionOr This allows us to use TRY in these functions :^).
2022-02-07 14:36:45 +01:00
interpreter.accumulator() = TRY(iterator_value(interpreter.global_object(), *iterator_result));
return {};
LibJS: Implement array destructuring for the bytecode interpreter
2021-06-13 13:40:48 -07:00
}
LibJS: Implement the NewClass opcode
2022-02-11 22:38:21 +03:30
ThrowCompletionOr<void> NewClass::execute_impl(Bytecode::Interpreter& interpreter) const
LibJS: NewClass bytecode instruction This adds a the NewClass bytecode instruction, enough of it is implemented for it to show it in the bytecode (js -d).
2021-06-30 15:42:13 -03:00
{
LibJS: Implement the NewClass opcode
2022-02-11 22:38:21 +03:30
auto name = m_class_expression.name();
auto scope = interpreter.ast_interpreter_scope();
auto& ast_interpreter = scope.interpreter();
auto class_object = TRY(m_class_expression.class_definition_evaluation(ast_interpreter, interpreter.global_object(), name, name.is_null() ? "" : name));
interpreter.accumulator() = class_object;
return {};
LibJS: NewClass bytecode instruction This adds a the NewClass bytecode instruction, enough of it is implemented for it to show it in the bytecode (js -d).
2021-06-30 15:42:13 -03:00
}
LibJS: 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: Add a separate "identifier table" to bytecode executables This is a specialized string table for storing identifiers only. Identifiers are always FlyStrings, which makes many common operations faster by allowing O(1) comparison.
2021-10-24 15:34:30 +02:00
return String::formatted("GetVariable {} ({})", m_identifier, executable.identifier_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: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
String CreateEnvironment::to_string_impl(Bytecode::Executable const&) const
{
auto mode_string = m_mode == EnvironmentMode::Lexical
? "Lexical"
: "Variable";
return String::formatted("CreateEnvironment mode:{}", mode_string);
}
String CreateVariable::to_string_impl(Bytecode::Executable const& executable) const
{
auto mode_string = m_mode == EnvironmentMode::Lexical ? "Lexical" : "Variable";
return String::formatted("CreateVariable env:{} immutable:{} {} ({})", mode_string, m_is_immutable, m_identifier, executable.identifier_table->get(m_identifier));
}
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: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
auto initialization_mode_name = m_initialization_mode == InitializationMode ::Initialize ? "Initialize"
: m_initialization_mode == InitializationMode::Set ? "Set"
: "InitializeOrSet";
auto mode_string = m_mode == EnvironmentMode::Lexical ? "Lexical" : "Variable";
return String::formatted("SetVariable env:{} init:{} {} ({})", mode_string, initialization_mode_name, m_identifier, executable.identifier_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: Add a separate "identifier table" to bytecode executables This is a specialized string table for storing identifiers only. Identifiers are always FlyStrings, which makes many common operations faster by allowing O(1) comparison.
2021-10-24 15:34:30 +02:00
return String::formatted("PutById base:{}, property:{} ({})", m_base, m_property, executable.identifier_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: Add a separate "identifier table" to bytecode executables This is a specialized string table for storing identifiers only. Identifiers are always FlyStrings, which makes many common operations faster by allowing O(1) comparison.
2021-10-24 15:34:30 +02:00
return String::formatted("GetById {} ({})", m_property, executable.identifier_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: Fix codegen for nodes after try statements without 'finally' Previously we were just dropping them on the ground :P
2021-11-10 22:22:26 +03:30
String FinishUnwind::to_string_impl(const Bytecode::Executable&) const
{
return String::formatted("FinishUnwind next:{}", m_next_target);
}
LibJS: More properly implement scoping rules in bytecode codegen Now we emit CreateVariable and SetVariable with the appropriate initialization/environment modes, much closer to the spec. This makes a whole lot of things like let/const variables, function and variable hoisting and some other things work :^)
2022-02-12 19:48:45 +03:30
String LeaveEnvironment::to_string_impl(Bytecode::Executable const&) const
{
auto mode_string = m_mode == EnvironmentMode::Lexical
? "Lexical"
: "Variable";
return String::formatted("LeaveEnvironment env:{}", mode_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 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: Implement 'this' in the bytecode VM ThisExpression now emits a "ResolveThisBinding" bytecode op, which simply loads the VM's current 'this' binding into the accumulator.
2021-10-24 14:43:00 +02:00
String ResolveThisBinding::to_string_impl(Bytecode::Executable const&) const
{
return "ResolveThisBinding"sv;
}
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