Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-24 10:03:21 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibJS/Bytecode/Generator.h

61 lines
1.5 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>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/OwnPtr.h>
LibJS: Add bytecode instruction handles This change removes the mmap inside of Block in favor of a growing vector of bytes. This is favorable for two reasons: - We don't take more space than we need - There is no limit to the growth of the vector (previously, if the Block overstepped its 64kb boundary, it would just crash) However, if that vector happens to resize, any pointer pointing into that vector would become invalid. To avoid this, this commit adds an InstructionHandle<Op> class which just stores a block and an offset into that block.
2021-06-08 14:46:46 -07:00
#include <LibJS/Bytecode/Block.h>
LibJS: Add basic support for while loops in the bytecode engine This introduces two new instructions: Jump and JumpIfFalse. Jumps are made to a Bytecode::Label, which is a simple object that represents a location in the bytecode stream. Note that you may not always know the target of a jump when adding the jump instruction itself, but we can just update the instruction later on during codegen once we know where the jump target is. The Bytecode::Interpreter now implements jumping via a jump slot that gets checked after each instruction to see if a jump is pending. If not, we just increment the PC as usual.
2021-06-04 12:07:38 +02:00
#include <LibJS/Bytecode/Label.h>
LibJS: 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/Forward.h>
namespace JS::Bytecode {
class Generator {
public:
static OwnPtr<Block> generate(ASTNode const&);
Register allocate_register();
template<typename OpType, typename... Args>
LibJS: Add bytecode instruction handles This change removes the mmap inside of Block in favor of a growing vector of bytes. This is favorable for two reasons: - We don't take more space than we need - There is no limit to the growth of the vector (previously, if the Block overstepped its 64kb boundary, it would just crash) However, if that vector happens to resize, any pointer pointing into that vector would become invalid. To avoid this, this commit adds an InstructionHandle<Op> class which just stores a block and an offset into that block.
2021-06-08 14:46:46 -07:00
InstructionHandle<OpType> emit(Args&&... args)
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: Add bytecode instruction handles This change removes the mmap inside of Block in favor of a growing vector of bytes. This is favorable for two reasons: - We don't take more space than we need - There is no limit to the growth of the vector (previously, if the Block overstepped its 64kb boundary, it would just crash) However, if that vector happens to resize, any pointer pointing into that vector would become invalid. To avoid this, this commit adds an InstructionHandle<Op> class which just stores a block and an offset into that block.
2021-06-08 14:46:46 -07:00
return make_instruction<OpType>(0, forward<Args>(args)...);
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
}
template<typename OpType, typename... Args>
LibJS: Add bytecode instruction handles This change removes the mmap inside of Block in favor of a growing vector of bytes. This is favorable for two reasons: - We don't take more space than we need - There is no limit to the growth of the vector (previously, if the Block overstepped its 64kb boundary, it would just crash) However, if that vector happens to resize, any pointer pointing into that vector would become invalid. To avoid this, this commit adds an InstructionHandle<Op> class which just stores a block and an offset into that block.
2021-06-08 14:46:46 -07:00
InstructionHandle<OpType> emit_with_extra_register_slots(size_t extra_register_slots, Args&&... args)
LibJS: Devirtualize and pack the bytecode stream :^) This patch changes the LibJS bytecode to be a stream of instructions packed one-after-the-other in contiguous memory, instead of a vector of OwnPtr<Instruction>. This should be a lot more cache-friendly. :^) Instructions are also devirtualized and instead have a type field using a new Instruction::Type enum. To iterate over a bytecode stream, one must now use Bytecode::InstructionStreamIterator.
2021-06-07 15:12:43 +02:00
{
LibJS: Add bytecode instruction handles This change removes the mmap inside of Block in favor of a growing vector of bytes. This is favorable for two reasons: - We don't take more space than we need - There is no limit to the growth of the vector (previously, if the Block overstepped its 64kb boundary, it would just crash) However, if that vector happens to resize, any pointer pointing into that vector would become invalid. To avoid this, this commit adds an InstructionHandle<Op> class which just stores a block and an offset into that block.
2021-06-08 14:46:46 -07:00
return make_instruction<OpType>(extra_register_slots, forward<Args>(args)...);
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: 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
Label make_label() const;
LibJS: Add basic support for "continue" in the bytecode VM Unlike the convoluted unwind-until-scope-type mechanism in the AST interpreter, "continue" maps to a simple Bytecode::Op::Jump here. :^) We know where to jump based on a stack of "continuable scopes" that we now maintain on the Bytecode::Generator as we go. Note that this only supports bare "continue", not continue-with-label.
2021-06-06 13:33:02 +02:00
void begin_continuable_scope();
void end_continuable_scope();
Label nearest_continuable_scope() 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
private:
Generator();
~Generator();
LibJS: Add bytecode instruction handles This change removes the mmap inside of Block in favor of a growing vector of bytes. This is favorable for two reasons: - We don't take more space than we need - There is no limit to the growth of the vector (previously, if the Block overstepped its 64kb boundary, it would just crash) However, if that vector happens to resize, any pointer pointing into that vector would become invalid. To avoid this, this commit adds an InstructionHandle<Op> class which just stores a block and an offset into that block.
2021-06-08 14:46:46 -07:00
template<typename OpType, typename... Args>
InstructionHandle<OpType> make_instruction(size_t extra_register_slots, Args&&... args)
{
auto& buffer = m_block->buffer();
auto offset = buffer.size();
buffer.resize(buffer.size() + sizeof(OpType) + extra_register_slots * sizeof(Register));
new (buffer.data() + offset) OpType(forward<Args>(args)...);
return InstructionHandle<OpType>(offset, m_block);
}
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
OwnPtr<Block> m_block;
u32 m_next_register { 1 };
LibJS: Add basic support for "continue" in the bytecode VM Unlike the convoluted unwind-until-scope-type mechanism in the AST interpreter, "continue" maps to a simple Bytecode::Op::Jump here. :^) We know where to jump based on a stack of "continuable scopes" that we now maintain on the Bytecode::Generator as we go. Note that this only supports bare "continue", not continue-with-label.
2021-06-06 13:33:02 +02:00
Vector<Label> m_continuable_scopes;
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