Avoids using multiple calls to fprintf() to print a single compile
error. This should make it easier to allow the host to provide a
callback function to print errors.
The compiler used to maintain all of the data that defines a function,
which it incrementally built up. Then, when it was done, it copied all
of that to a new ObjFn. In theory, that was to trim down some memory
and avoid unneeded fields in ObjFn.
In practice, the performance benefit is negligible and the memory saving
is nullified by the fact that it copies anyway.
This moves all of that mutable state directly into ObjFn. The compiler
creates a new empty ObjFn at the beginning and then just fills it in
in place.
This shaves off about 40 lines of code, is simpler, and doesn't seem to
impact perf.
My first attempt to embed VM in project ended with crash. Fortunately I'm not so easly scared and managed to found out that despite comment in "wren.h" no check for null is performed. I took the liberty of fixing that.
Btw. nice project, keep up the good work!
This is simpler than having special opcodes for them. It's also a bit
faster, and gets some non-critical code out of the interpreter loop.
Also, this is good prep work for being able to write some of the module
loading process in Wren to make things more flexible for embedders and
the CLI.
This is not implemented on Sequence because, at least for lists and
strings, I think users expect an eager result. Multiplying a string
should give you back a string, not a lazy sequence of repeated
characters.
This also mirrors "+" on strings and lists, which is eager. I like the
idea of having a general guideline that operators are eager.
Repetition is useful for arbitrary sequences, but for that maybe we
should add a "repeat()" method.
Instead of copying the uv_fs_stat struct to a list of Wren numbers, we
store it directly in the Stat object. This is important because we'll
need to implement later methods like isDirectory() in C so we can use
S_ISDIR(). For that, we need to have access to the original stat data.
Gets rid of the slightly ugly loadInstruction output parameter that
gets passed around. Now a reference to a variable is a first-class
concept in the compiler.
Now, you call wrenEnsureSlots() and then wrenSetSlot___() to set up the
receiver and arguments before the call. Then wrenCall() is passed a
handle to the stub function that makes the call. After that, you can
get the result using wrenGetSlot___().
This is a little more verbose to use, but it's more flexible, simpler,
and much faster in the VM. The call benchmark is 185% of the previous
speed.
Instead, finalizers just get access to the foreign object's raw bytes.
This is deliberately limiting, since it discourages the user from
interacting with the VM in the middle of a GC.
- wrenEnsureSlots()
Lets you go the foreign slot stack to make room for a temporary work
area.
- wrenSetSlotNewList()
Creates a new empty list and stores it in a slot.
- wrenInsertInList()
Takes a value from one slot and inserts it into the list in another.
Still need more functions like getting elements from a list, removing,
etc. but this at least lets you create, populate, and return lists from
foreign methods.
This turns those functions into general-purpose functions for writing
raw C values into slots on the foreign call stack.
Writing a return just means writing a value to slot 0.
- wrenGetArgumentCount() -> wrenGetSlotCount()
- wrenGetArgument___() -> wrenGetSlot___()
Also, the get functions assert that the value is the right type instead
of checking at runtime. This puts the onus on the caller to be safe,
but maximizes performance.
This is the first step towards dynamically grown stacks. We don't want
to check for stack overflow on every single push, so we store the max
number of slots a function might need and (in later patches) ensure
at function call time that that many slots are available.
Stephen Belanger
Bob Nystrom
MADGameStudio