beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-22 07:30:19 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/Libraries/LibJS/Bytecode/Instruction.h

220 lines
7.4 KiB
C
Raw Permalink Normal View History

LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 08:46:30 +00:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 11:19:50 +00:00
* Copyright (c) 2021-2024, Andreas Kling <andreas@ladybird.org>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 08:46:30 +00:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/Forward.h>
LibJS/Bytecode: Keep instruction source mappings in Executable Instead of storing source offsets with each instruction, we now keep them in a side table in Executable. This shrinks each instruction by 8 bytes, further improving locality.
2024-05-06 05:51:14 +00:00
#include <AK/Function.h>
LibJS: Always inline the bytecode instruction iterator's operator++
2021-10-25 11:37:02 +00:00
#include <AK/Span.h>
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 14:53:55 +00:00
#include <LibJS/Bytecode/Executable.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 08:46:30 +00:00
#include <LibJS/Forward.h>
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 14:53:55 +00:00
#include <LibJS/SourceRange.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 08:46:30 +00:00
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
#define ENUMERATE_BYTECODE_OPS(O) \
O(Add) \
LibJS: Stop using execute_ast_node() for class property evaluation Instead, generate bytecode to execute their AST nodes and save the resulting operands inside the NewClass instruction. Moving property expression evaluation to happen before NewClass execution also moves along creation of new private environment and its population with private members (private members should be visible during property evaluation). Before: - NewClass After: - CreatePrivateEnvironment - AddPrivateName - ... - AddPrivateName - NewClass - LeavePrivateEnvironment
2024-05-11 22:54:41 +00:00
O(AddPrivateName) \
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 07:00:54 +00:00
O(ArrayAppend) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(AsyncIteratorClose) \
O(Await) \
O(BitwiseAnd) \
O(BitwiseNot) \
O(BitwiseOr) \
O(BitwiseXor) \
O(BlockDeclarationInstantiation) \
O(Call) \
LibJS: Split `Call` Instruction by `CallType` Instead of branching on the `CallType` at runtime in a hot instruction like `Call`, lets emit separate instructions for each call type during codegen.
2024-10-31 21:47:30 +00:00
O(CallBuiltin) \
O(CallConstruct) \
O(CallDirectEval) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(CallWithArgumentArray) \
LibJS/JIT: Update "unwind context" stack in JIT code Until now, the unwind context stack has not been maintained by jitted code, which meant we were unable to support the `with` statement. This is a first step towards supporting that by making jitted code call out to C++ to update the unwind context stack when entering/leaving unwind contexts. We also introduce a new "Catch" bytecode instruction that moves the current exception into the accumulator. It's always emitted at the start of a "catch" block.
2023-11-11 22:19:46 +00:00
O(Catch) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(ConcatString) \
O(ContinuePendingUnwind) \
O(CopyObjectExcludingProperties) \
LibJS/Bytecode: Sort ENUMERATE_BYTECODE_OPS list
2024-05-14 09:06:12 +00:00
O(CreateArguments) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(CreateLexicalEnvironment) \
LibJS: Stop using execute_ast_node() for class property evaluation Instead, generate bytecode to execute their AST nodes and save the resulting operands inside the NewClass instruction. Moving property expression evaluation to happen before NewClass execution also moves along creation of new private environment and its population with private members (private members should be visible during property evaluation). Before: - NewClass After: - CreatePrivateEnvironment - AddPrivateName - ... - AddPrivateName - NewClass - LeavePrivateEnvironment
2024-05-11 22:54:41 +00:00
O(CreatePrivateEnvironment) \
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 20:06:55 +00:00
O(CreateRestParams) \
LibJS/Bytecode: Sort ENUMERATE_BYTECODE_OPS list
2024-05-14 09:06:12 +00:00
O(CreateVariable) \
O(CreateVariableEnvironment) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(Decrement) \
O(DeleteById) \
O(DeleteByIdWithThis) \
O(DeleteByValue) \
O(DeleteByValueWithThis) \
O(DeleteVariable) \
O(Div) \
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 07:00:54 +00:00
O(Dump) \
O(End) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(EnterObjectEnvironment) \
LibJS: Cleanup unwind state when transferring control out of a finalizer This does two things: * Clear exceptions when transferring control out of a finalizer Otherwise they would resurface at the end of the next finalizer (see test the new test case), or at the end of a function * Pop one scheduled jump when transferring control out of a finalizer This removes one old FIXME
2024-04-11 09:58:18 +00:00
O(EnterUnwindContext) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(Exp) \
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 20:06:55 +00:00
O(GetArgument) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(GetById) \
O(GetByIdWithThis) \
O(GetByValue) \
O(GetByValueWithThis) \
O(GetCalleeAndThisFromEnvironment) \
LibJS/Bytecode: Sort ENUMERATE_BYTECODE_OPS list
2024-05-14 09:06:12 +00:00
O(GetGlobal) \
O(GetImportMeta) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(GetIterator) \
LibJS/Bytecode: Add dedicated instruction for getting `length` property By doing this, we can remove all the special-case checks for `length` from the generic GetById and GetByIdWithThis code paths, making every other property lookup a bit faster. Small progressions on most benchmarks, and some larger progressions: - 12% on Octane/crypto.js - 6% on Kraken/ai-astar.js
2024-05-20 09:53:28 +00:00
O(GetLength) \
O(GetLengthWithThis) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(GetMethod) \
O(GetNewTarget) \
LibJS: Stop converting between Object <-> IteratorRecord all the time This patch makes IteratorRecord an Object. Although it's not exposed to author code, this does allow us to store it in a VM register. Now that we can store it in a VM register, we don't need to convert it back and forth between IteratorRecord and Object when accessing it from bytecode. The big win here is avoiding 3 [[Get]] accesses on every iteration step of for..of loops. There are also a bunch of smaller efficiencies gained. 20% speed-up on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 09:44:41 +00:00
O(GetNextMethodFromIteratorRecord) \
LibJS: Cleanup unwind state when transferring control out of a finalizer This does two things: * Clear exceptions when transferring control out of a finalizer Otherwise they would resurface at the end of the next finalizer (see test the new test case), or at the end of a function * Pop one scheduled jump when transferring control out of a finalizer This removes one old FIXME
2024-04-11 09:58:18 +00:00
O(GetObjectFromIteratorRecord) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(GetObjectPropertyIterator) \
O(GetPrivateById) \
LibJS/Bytecode: Rename GetVariable => GetBinding
2024-05-14 09:32:04 +00:00
O(GetBinding) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(GreaterThan) \
O(GreaterThanEquals) \
O(HasPrivateId) \
O(ImportCall) \
O(In) \
O(Increment) \
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 09:30:30 +00:00
O(InitializeLexicalBinding) \
O(InitializeVariableBinding) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(InstanceOf) \
O(IteratorClose) \
O(IteratorNext) \
O(IteratorToArray) \
O(Jump) \
LibJS/Bytecode: Turn JumpIf condition,@a,@next into JumpTrue/JumpFalse If one of the jump targets is the very next block, we can convert the jump instruction into a smaller JumpTrue or JumpFalse.
2024-05-06 08:15:17 +00:00
O(JumpFalse) \
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 13:13:31 +00:00
O(JumpGreaterThan) \
O(JumpGreaterThanEquals) \
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 07:00:54 +00:00
O(JumpIf) \
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 13:13:31 +00:00
O(JumpLessThan) \
O(JumpLessThanEquals) \
O(JumpLooselyEquals) \
O(JumpLooselyInequals) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(JumpNullish) \
LibJS/Bytecode: Do basic compare-and-jump peephole optimization We now fuse sequences like [LessThan, JumpIf] to JumpLessThan. This is only allowed for temporaries (i.e VM registers) with no other references to them.
2024-05-09 13:13:31 +00:00
O(JumpStrictlyEquals) \
O(JumpStrictlyInequals) \
LibJS/Bytecode: Turn JumpIf condition,@a,@next into JumpTrue/JumpFalse If one of the jump targets is the very next block, we can convert the jump instruction into a smaller JumpTrue or JumpFalse.
2024-05-06 08:15:17 +00:00
O(JumpTrue) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(JumpUndefined) \
LibJS: Cleanup unwind state when transferring control out of a finalizer This does two things: * Clear exceptions when transferring control out of a finalizer Otherwise they would resurface at the end of the next finalizer (see test the new test case), or at the end of a function * Pop one scheduled jump when transferring control out of a finalizer This removes one old FIXME
2024-04-11 09:58:18 +00:00
O(LeaveFinally) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(LeaveLexicalEnvironment) \
LibJS: Stop using execute_ast_node() for class property evaluation Instead, generate bytecode to execute their AST nodes and save the resulting operands inside the NewClass instruction. Moving property expression evaluation to happen before NewClass execution also moves along creation of new private environment and its population with private members (private members should be visible during property evaluation). Before: - NewClass After: - CreatePrivateEnvironment - AddPrivateName - ... - AddPrivateName - NewClass - LeavePrivateEnvironment
2024-05-11 22:54:41 +00:00
O(LeavePrivateEnvironment) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(LeaveUnwindContext) \
O(LeftShift) \
O(LessThan) \
O(LessThanEquals) \
O(LooselyEquals) \
O(LooselyInequals) \
O(Mod) \
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 07:00:54 +00:00
O(Mov) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(Mul) \
O(NewArray) \
O(NewClass) \
O(NewFunction) \
O(NewObject) \
LibJS: Instantiate primitive array expressions using a single operation This will not meaningfully affect short array literals, but it does give us a bit of extra perf when evaluating huge array expressions like in Kraken/imaging-darkroom.js
2023-11-17 20:07:23 +00:00
O(NewPrimitiveArray) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(NewRegExp) \
O(NewTypeError) \
O(Not) \
LibJS: Prepare yield object before re-routing it through finally
2024-05-18 15:25:43 +00:00
O(PrepareYield) \
LibJS/Bytecode: Dedicated instructions for postfix increment/decrement Instead of splitting the postfix variants into ToNumeric + Inc/Dec, we now have dedicated PostfixIncrement and PostfixDecrement instructions that handle both outputs in one go.
2024-02-20 10:45:01 +00:00
O(PostfixDecrement) \
O(PostfixIncrement) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(PutById) \
O(PutByIdWithThis) \
LibJS: Add `PutBySpread` instruction This object property kind had completely different behaviour. By adding an instruction for it, we can remove a bunch of special casing, and avoid creating dummy `PropertyKey` values.
2024-11-01 21:00:32 +00:00
O(PutBySpread) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(PutByValue) \
O(PutByValueWithThis) \
O(PutPrivateById) \
O(ResolveSuperBase) \
LibJS/Bytecode: Sort ENUMERATE_BYTECODE_OPS list
2024-05-14 09:06:12 +00:00
O(ResolveThisBinding) \
LibJS: Restore scheduled jumps in catch blocks without finalizers
2024-04-11 09:07:35 +00:00
O(RestoreScheduledJump) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(Return) \
O(RightShift) \
O(ScheduleJump) \
LibJS: Emit bytecode for function declaration instantiation By doing that all instructions required for instantiation are emitted once in compilation and then reused for subsequent calls, instead of running generic instantiation process for each call.
2024-05-05 20:06:55 +00:00
O(SetArgument) \
LibJS/Bytecode: Split SetVariable into four separate instructions Instead of SetVariable having 2x2 modes for variable/lexical and initialize/set, those 4 modes are now separate instructions, which makes each instruction much less branchy.
2024-05-14 09:30:30 +00:00
O(SetLexicalBinding) \
O(SetVariableBinding) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(StrictlyEquals) \
O(StrictlyInequals) \
O(Sub) \
O(SuperCallWithArgumentArray) \
O(Throw) \
O(ThrowIfNotObject) \
O(ThrowIfNullish) \
LibJS/Bytecode: Move to a new bytecode format This patch moves us away from the accumulator-based bytecode format to one with explicit source and destination registers. The new format has multiple benefits: - ~25% faster on the Kraken and Octane benchmarks :^) - Fewer instructions to accomplish the same thing - Much easier for humans to read(!) Because this change requires a fundamental shift in how bytecode is generated, it is quite comprehensive. Main implementation mechanism: generate_bytecode() virtual function now takes an optional "preferred dst" operand, which allows callers to communicate when they have an operand that would be optimal for the result to go into. It also returns an optional "actual dst" operand, which is where the completion value (if any) of the AST node is stored after the node has "executed". One thing of note that's new: because instructions can now take locals as operands, this means we got rid of the GetLocal instruction. A side-effect of that is we have to think about the temporal deadzone (TDZ) a bit differently for locals (GetLocal would previously check for empty values and interpret that as a TDZ access and throw). We now insert special ThrowIfTDZ instructions in places where a local access may be in the TDZ, to maintain the correct behavior. There are a number of progressions and regressions from this test: A number of async generator tests have been accidentally fixed while converting the implementation to the new bytecode format. It didn't seem useful to preserve bugs in the original code when converting it. Some "does eval() return the correct completion value" tests have regressed, in particular ones related to propagating the appropriate completion after control flow statements like continue and break. These are all fairly obscure issues, and I believe we can continue working on them separately. The net test262 result is a progression though. :^)
2024-02-04 07:00:54 +00:00
O(ThrowIfTDZ) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(Typeof) \
LibJS/Bytecode: Rename TypeofVariable => TypeofBinding
2024-06-14 07:37:26 +00:00
O(TypeofBinding) \
LibJS: Use correct `this` value when callee is a `with` binding If we're inside of a `with` statement scope, we have to take care to extract the correct `this` value for use in calls when calling a method on the binding object via an Identifier instead of a MemberExpression. This makes Vue.js work way better in the bytecode VM. :^) Also, 1 new pass on test262.
2023-08-01 12:33:58 +00:00
O(UnaryMinus) \
O(UnaryPlus) \
O(UnsignedRightShift) \
LibJS: Alphabetize the bytecode opcode list
2021-10-24 12:38:57 +00:00
O(Yield)
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 13:12:43 +00:00
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 08:46:30 +00:00
namespace JS::Bytecode {
LibJS: Align Instructions as void* and roundup variably sized ones sizes Both is indeed needed, the standard alignment would have been 4, but some Instructions, like Jumps need an alignment of 8 Fixes #12127.
2022-09-09 14:47:42 +00:00
class alignas(void*) Instruction {
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 08:46:30 +00:00
public:
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 02:19:58 +00:00
constexpr static bool IsTerminator = false;
LibJS/Bytecode: Unroll the bytecode interpreter This commit adds a HANDLE_INSTRUCTION macro that expands to everything needed to handle a single instruction (invoking the handler function, checking for exceptions, and advancing the program counter). This gives a ~15% speed-up on a for loop microbenchmark, and makes basically everything faster.
2024-05-06 08:42:52 +00:00
static constexpr bool IsVariableLength = false;
LibJS: Generate bytecode in basic blocks instead of one big block This limits the size of each block (currently set to 1K), and gets us closer to a canonical, more easily analysable bytecode format. As a result of this, "Labels" are now simply entries to basic blocks. Since there is no more 'conditional' jump (as all jumps are always taken), JumpIf{True,False} are unified to JumpConditional, and JumpIfNullish is renamed to JumpNullish. Also fixes #7914 as a result of reimplementing the loop logic.
2021-06-09 02:19:58 +00:00
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 13:12:43 +00:00
enum class Type {
#define __BYTECODE_OP(op) \
op,
ENUMERATE_BYTECODE_OPS(__BYTECODE_OP)
#undef __BYTECODE_OP
};
Type type() const { return m_type; }
LibJS/Bytecode: Remove Instruction::m_length field Now that the interpreter is unrolled, we can advance the program counter manually based on the current instruction type. This makes most instructions a bit smaller. :^)
2024-05-06 09:09:09 +00:00
size_t length() const;
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 14:19:34 +00:00
ByteString to_byte_string(Bytecode::Executable const&) const;
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 04:44:08 +00:00
void visit_labels(Function<void(Label&)> visitor);
LibJS: Join locals, constants and registers into single vector Merging registers, constants and locals into single vector means: - Better data locality - No need to check type in Interpreter::get() and Interpreter::set() which are very hot functions Performance improvement is visible in almost all Octane and Kraken tests.
2024-05-12 16:49:03 +00:00
void visit_operands(Function<void(Operand&)> visitor);
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 13:12:43 +00:00
static void destroy(Instruction&);
protected:
LibJS/Bytecode: Remove Instruction::m_length field Now that the interpreter is unrolled, we can advance the program counter manually based on the current instruction type. This makes most instructions a bit smaller. :^)
2024-05-06 09:09:09 +00:00
explicit Instruction(Type type)
: m_type(type)
{
}
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 08:46:30 +00:00
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 04:44:08 +00:00
void visit_labels_impl(Function<void(Label&)>) { }
LibJS: Join locals, constants and registers into single vector Merging registers, constants and locals into single vector means: - Better data locality - No need to check type in Interpreter::get() and Interpreter::set() which are very hot functions Performance improvement is visible in almost all Octane and Kraken tests.
2024-05-12 16:49:03 +00:00
void visit_operands_impl(Function<void(Operand&)>) { }
LibJS/Bytecode: Flatten bytecode to a contiguous representation Instead of keeping bytecode as a set of disjoint basic blocks on the malloc heap, bytecode is now a contiguous sequence of bytes(!) The transformation happens at the end of Bytecode::Generator::generate() and the only really hairy part is rerouting jump labels. This required solving a few problems: - The interpreter execution loop had to change quite a bit, since we were storing BasicBlock pointers all over the place, and control transfer was done by redirecting the interpreter's current block. - Exception handlers & finalizers are now stored per-bytecode-range in a side table in Executable. - The interpreter now has a plain program counter instead of a stream iterator. This actually makes error stack generation a bit nicer since we just have to deal with a number instead of reaching into the iterator. This yields a 25% performance improvement on this microbenchmark: for (let i = 0; i < 1_000_000; ++i) { } But basically everything gets faster. :^)
2024-05-06 04:44:08 +00:00
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 13:12:43 +00:00
private:
Type m_type {};
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 08:46:30 +00:00
};
LibJS: Always inline the bytecode instruction iterator's operator++
2021-10-25 11:37:02 +00:00
class InstructionStreamIterator {
public:
LibJS/JIT: Provide source location information for JIT code This works by walking a backtrace until the currently executing native executable is found, and then mapping the native address to its bytecode instruction.
2023-10-30 21:06:27 +00:00
InstructionStreamIterator(ReadonlyBytes bytes, Executable const* executable = nullptr, size_t offset = 0)
LibJS: Streamline InstructionStreamIterator Nuke all the per-instruction bounds checking when iterating instructions by using raw pointers instead of indexing into a ReadonlyBytes. The interpreter loop already checks that we're in-bounds anyway.
2023-09-26 14:03:42 +00:00
: m_begin(bytes.data())
, m_end(bytes.data() + bytes.size())
LibJS/JIT: Provide source location information for JIT code This works by walking a backtrace until the currently executing native executable is found, and then mapping the native address to its bytecode instruction.
2023-10-30 21:06:27 +00:00
, m_ptr(bytes.data() + offset)
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 14:53:55 +00:00
, m_executable(executable)
LibJS: Always inline the bytecode instruction iterator's operator++
2021-10-25 11:37:02 +00:00
{
}
LibJS: Streamline InstructionStreamIterator Nuke all the per-instruction bounds checking when iterating instructions by using raw pointers instead of indexing into a ReadonlyBytes. The interpreter loop already checks that we're in-bounds anyway.
2023-09-26 14:03:42 +00:00
size_t offset() const { return m_ptr - m_begin; }
bool at_end() const { return m_ptr >= m_end; }
LibJS: Always inline the bytecode instruction iterator's operator++
2021-10-25 11:37:02 +00:00
Instruction const& operator*() const { return dereference(); }
ALWAYS_INLINE void operator++()
{
LibJS: Streamline InstructionStreamIterator Nuke all the per-instruction bounds checking when iterating instructions by using raw pointers instead of indexing into a ReadonlyBytes. The interpreter loop already checks that we're in-bounds anyway.
2023-09-26 14:03:42 +00:00
m_ptr += dereference().length();
LibJS: Always inline the bytecode instruction iterator's operator++
2021-10-25 11:37:02 +00:00
}
LibJS: Add file & line number to bytecode VM stack traces :^) This works by adding source start/end offset to every bytecode instruction. In the future we can make this more efficient by keeping a map of bytecode ranges to source ranges in the Executable instead, but let's just get traces working first. Co-Authored-By: Andrew Kaster <akaster@serenityos.org>
2023-09-01 14:53:55 +00:00
UnrealizedSourceRange source_range() const;
RefPtr<SourceCode> source_code() const;
LibJS: Make Executable ref-counted and let instruction iterator co-own it This ensures that the instruction stream pointed at by the instruction iterator remains valid as long as the iterator exists.
2023-10-03 06:18:10 +00:00
Executable const* executable() const { return m_executable; }
LibJS: Always inline the bytecode instruction iterator's operator++
2021-10-25 11:37:02 +00:00
private:
LibJS: Streamline InstructionStreamIterator Nuke all the per-instruction bounds checking when iterating instructions by using raw pointers instead of indexing into a ReadonlyBytes. The interpreter loop already checks that we're in-bounds anyway.
2023-09-26 14:03:42 +00:00
Instruction const& dereference() const { return *reinterpret_cast<Instruction const*>(m_ptr); }
LibJS: Always inline the bytecode instruction iterator's operator++
2021-10-25 11:37:02 +00:00
LibJS: Streamline InstructionStreamIterator Nuke all the per-instruction bounds checking when iterating instructions by using raw pointers instead of indexing into a ReadonlyBytes. The interpreter loop already checks that we're in-bounds anyway.
2023-09-26 14:03:42 +00:00
u8 const* m_begin { nullptr };
u8 const* m_end { nullptr };
u8 const* m_ptr { nullptr };
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 15:01:23 +00:00
GC::Ptr<Executable const> m_executable;
LibJS: Always inline the bytecode instruction iterator's operator++
2021-10-25 11:37:02 +00:00
};
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 08:46:30 +00:00
}
Reference in a new issue Copy permalink