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

191 lines
5.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
*/
LibJS: Add a new EnterScope bytecode instruction This is intended to perform the same duties as enter_scope() does in the AST tree-walk interpreter: - Hoisted function declaration processing - Hoisted variable declaration processing - ... maybe more This first cut only implements the function declaration processing.
2021-06-05 15:14:09 +02:00
#include <LibJS/AST.h>
LibJS: Start fleshing out a bytecode for the JavaScript engine :^) This patch begins the work of implementing JavaScript execution in a bytecode VM instead of an AST tree-walk interpreter. It's probably quite naive, but we have to start somewhere. The basic idea is that you call Bytecode::Generator::generate() on an AST node and it hands you back a Bytecode::Block filled with instructions that can then be interpreted by a Bytecode::Interpreter. This first version only implements two instructions: Load and Add. :^) Each bytecode block has infinity registers, and the interpreter resizes its register file to fit the block being executed. Two new `js` options are added in this patch as well: `-d` will dump the generated bytecode `-b` will execute the generated bytecode Note that unless `-d` and/or `-b` are specified, none of the bytecode related stuff in LibJS runs at all. This is implemented in parallel with the existing AST interpreter. :^)
2021-06-03 10:46:30 +02:00
#include <LibJS/Bytecode/Interpreter.h>
#include <LibJS/Bytecode/Op.h>
LibJS: 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: Add a new EnterScope bytecode instruction This is intended to perform the same duties as enter_scope() does in the AST tree-walk interpreter: - Hoisted function declaration processing - Hoisted variable declaration processing - ... maybe more This first cut only implements the function declaration processing.
2021-06-05 15:14:09 +02:00
#include <LibJS/Runtime/ScriptFunction.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>
namespace JS::Bytecode::Op {
void Load::execute(Bytecode::Interpreter& interpreter) const
{
interpreter.reg(m_dst) = m_value;
}
void Add::execute(Bytecode::Interpreter& interpreter) const
{
interpreter.reg(m_dst) = add(interpreter.global_object(), interpreter.reg(m_src1), interpreter.reg(m_src2));
}
LibJS: Add Sub bytecode instruction (subtract values)
2021-06-03 18:32:33 +02:00
void Sub::execute(Bytecode::Interpreter& interpreter) const
{
interpreter.reg(m_dst) = sub(interpreter.global_object(), interpreter.reg(m_src1), interpreter.reg(m_src2));
}
LibJS: Add LessThan bytecode instruction :^)
2021-06-04 12:03:57 +02:00
void LessThan::execute(Bytecode::Interpreter& interpreter) const
{
interpreter.reg(m_dst) = less_than(interpreter.global_object(), interpreter.reg(m_src1), interpreter.reg(m_src2));
}
LibJS: Add AbstractInequals bytecode instruction :^)
2021-06-04 12:18:06 +02:00
void AbstractInequals::execute(Bytecode::Interpreter& interpreter) const
{
interpreter.reg(m_dst) = Value(!abstract_eq(interpreter.global_object(), interpreter.reg(m_src1), interpreter.reg(m_src2)));
}
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
void NewString::execute(Bytecode::Interpreter& interpreter) const
{
interpreter.reg(m_dst) = js_string(interpreter.vm(), m_string);
}
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 20:30:23 +02:00
void NewObject::execute(Bytecode::Interpreter& interpreter) const
{
interpreter.reg(m_dst) = Object::create_empty(interpreter.global_object());
}
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
void GetVariable::execute(Bytecode::Interpreter& interpreter) const
{
interpreter.reg(m_dst) = interpreter.vm().get_variable(m_identifier, interpreter.global_object());
}
void SetVariable::execute(Bytecode::Interpreter& interpreter) const
{
interpreter.vm().set_variable(m_identifier, interpreter.reg(m_src), interpreter.global_object());
}
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
void GetById::execute(Bytecode::Interpreter& interpreter) const
{
if (auto* object = interpreter.reg(m_base).to_object(interpreter.global_object()))
interpreter.reg(m_dst) = object->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
void PutById::execute(Bytecode::Interpreter& interpreter) const
{
if (auto* object = interpreter.reg(m_base).to_object(interpreter.global_object()))
object->put(m_property, interpreter.reg(m_src));
}
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
void Jump::execute(Bytecode::Interpreter& interpreter) const
{
interpreter.jump(m_target);
}
void JumpIfFalse::execute(Bytecode::Interpreter& interpreter) const
{
VERIFY(m_target.has_value());
auto result = interpreter.reg(m_result);
if (!result.as_bool())
interpreter.jump(m_target.value());
}
LibJS: Generate bytecode for do...while statements :^) This was quite straightforward using the same label/jump machinery that we added for while statements. The main addition here is a new JumpIfTrue bytecode instruction.
2021-06-04 12:20:44 +02:00
void JumpIfTrue::execute(Bytecode::Interpreter& interpreter) const
{
VERIFY(m_target.has_value());
auto result = interpreter.reg(m_result);
if (result.as_bool())
interpreter.jump(m_target.value());
}
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
void EnterScope::execute(Bytecode::Interpreter& interpreter) const
{
auto& vm = interpreter.vm();
auto& global_object = interpreter.global_object();
for (auto& declaration : m_scope_node.functions())
vm.current_scope()->put_to_scope(declaration.name(), { js_undefined(), DeclarationKind::Var });
for (auto& declaration : m_scope_node.functions()) {
auto* function = ScriptFunction::create(global_object, declaration.name(), declaration.body(), declaration.parameters(), declaration.function_length(), vm.current_scope(), declaration.is_strict_mode());
vm.set_variable(declaration.name(), function, global_object);
}
// FIXME: Process variable declarations.
// FIXME: Whatever else JS::Interpreter::enter_scope() does.
}
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
String Load::to_string() const
{
LibJS: Add formatting helper for Bytecode::Register
2021-06-03 18:29:30 +02:00
return String::formatted("Load dst:{}, value:{}", m_dst, m_value.to_string_without_side_effects());
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
}
String Add::to_string() const
{
LibJS: Add formatting helper for Bytecode::Register
2021-06-03 18:29:30 +02:00
return String::formatted("Add dst:{}, src1:{}, src2:{}", m_dst, m_src1, m_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: Add Sub bytecode instruction (subtract values)
2021-06-03 18:32:33 +02:00
String Sub::to_string() const
{
return String::formatted("Sub dst:{}, src1:{}, src2:{}", m_dst, m_src1, m_src2);
}
LibJS: Add LessThan bytecode instruction :^)
2021-06-04 12:03:57 +02:00
String LessThan::to_string() const
{
return String::formatted("LessThan dst:{}, src1:{}, src2:{}", m_dst, m_src1, m_src2);
}
LibJS: Add AbstractInequals bytecode instruction :^)
2021-06-04 12:18:06 +02:00
String AbstractInequals::to_string() const
{
return String::formatted("AbstractInequals dst:{}, src1:{}, src2:{}", m_dst, m_src1, m_src2);
}
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
String NewString::to_string() const
{
LibJS: Add formatting helper for Bytecode::Register
2021-06-03 18:29:30 +02:00
return String::formatted("NewString dst:{}, string:\"{}\"", m_dst, m_string);
LibJS: Some more opcodes for the bytecode VM - NewString (allocates a new PrimitiveString from the GC heap) - GetVariable (retrieves a variable in the current scope) - SetVariable (assigns a variable in the current scope)
2021-06-03 18:26:32 +02:00
}
LibJS: Add a NewObject bytecode instruction for ObjectExpression :^)
2021-06-04 20:30:23 +02:00
String NewObject::to_string() const
{
return String::formatted("NewObject dst:{}", m_dst);
}
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
String GetVariable::to_string() const
{
LibJS: Add formatting helper for Bytecode::Register
2021-06-03 18:29:30 +02:00
return String::formatted("GetVariable dst:{}, identifier:{}", m_dst, 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
}
String SetVariable::to_string() const
{
LibJS: Add formatting helper for Bytecode::Register
2021-06-03 18:29:30 +02:00
return String::formatted("SetVariable identifier:{}, src:{}", m_identifier, m_src);
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 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
String PutById::to_string() const
{
return String::formatted("PutById base:{}, property:{}, src:{}", m_base, m_property, m_src);
}
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
String GetById::to_string() const
{
return String::formatted("GetById dst:{}, base:{}, property:{}", m_dst, m_base, m_property);
}
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
String Jump::to_string() const
{
return String::formatted("Jump {}", m_target);
}
String JumpIfFalse::to_string() const
{
if (m_target.has_value())
return String::formatted("JumpIfFalse result:{}, target:{}", m_result, m_target.value());
return String::formatted("JumpIfFalse result:{}, target:<empty>", m_result);
}
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
String JumpIfTrue::to_string() const
{
if (m_target.has_value())
return String::formatted("JumpIfTrue result:{}, target:{}", m_result, m_target.value());
return String::formatted("JumpIfTrue result:{}, target:<empty>", m_result);
}
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
String EnterScope::to_string() const
{
return "EnterScope";
}
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