| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
When evaluated as an expression "if (true) { 3 } else { 5 }"
should yield 3. This updates the bytecode interpreter to make
it so.
|
|
When evaluated as an expression "{ 3 }" should yield 3. This updates
the bytecode interpreter to make it so.
|
|
When samples are requested in `Audio::Loader::get_more_samples`,
the request comes in as a max number of bytes to read.
However, the requested number of bytes may not be an even multiple
of the bytes per sample of the loaded file. If this is the case, and
the bytes are read from the file/stream, then
the last sample will be a partial/runt sample, which then offsets
the remainder of the stream, causing white noise in playback.
This bug was discovered when trying to play 24-bit Wave files, which
happened to have a sample size that never aligned with the number
of requested bytes.
This commit fixes the bug by only reading a multiple of
"bytes per sample" for the loaded file.
|
|
IODeviceStreamReader isn't pulling its weight.
It's essentially a subset of InputFileStream with only one user
(WavLoader).
This refactors WavLoader to use InputFileStream instead.
|
|
When the cursor is clicked outside of the slider knob,
the current behavior is that it will step up or down by the
Slider page step amount.
This commit adds an option to jump the slider knob
directly to the where the mouse cursor is on mouse down events.
This behavior is disabled by default. It must be enabled with
`Slider::set_jump_to_cursor()`.
Jump to cursor is enabled in SoundPlayer since most music players
have this behavior.
|
|
|
|
|
|
|
|
|
|
|
|
No-op. :^)
|
|
~, !, +, -, typeof, and void.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
After compiling bytecode, we should mark the memory read-only.
This currently does not work because it breaks instruction destruction.
I'm adding this anyway with a FIXME so we don't forget about it. :^)
|
|
It's silly to generate new bytecode every time you call a function.
Let's just cache the code instead. :^)
|
|
|
|
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.
|
|
Otherwise it will cause complete unwind since all parent run() loops
will see the same m_return_value being non-empty and break out.
|
|
The Bytecode::Interpreter will push a global call frame if needed,
and it needs to make sure that call frame survives until the end
of the Interpreter::run() function.
|
|
|
|
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.
|
|
This also required making Bytecode::Op::Jump support lazy linking
to a target label.
I left a FIXME here about having the "if" statement return the result
value from the taken branch statement. That's what the AST interpreter
does but I'm not sure if it's actually required.
|
|
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! :^)
|
|
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.
|
|
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.
|
|
Note that we don't yet support nested calls using bytecode.
|
|
Same as PutById but in the other direction. :^)
|
|
Note that this is only used for non-computed accesses. Computed access
is not yet implemented. :^)
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
This will be useful for instructions that need to be modified later on
during code generation, e.g jumps. :^)
|
|
This will hopefully make it a bit more pleasant to edit this, as things
will just get larger and larger.
|
|
|
|
|
|
- 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)
|
|
|
|
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. :^)
|
