I've just run into a minor issue while adding argument count
checking to natively compiled blocks. A block needs to check that
it's getting called with the right number of arguments when it's
valued. The interpreter's BlockContexts contain an argument count
so it's easy to do the check. ExuperyBlockContexts don't and don't
have any spare slots.
The reason there's no spare slots is compiled contexts don't use
the interpreted instruction pointer. The instruction pointer is nilled
out occasionally so it's not suitable to hold the argument size.
My options are:
1) Rejig compiled contexts so compiled MethodContexts are the
closer as ExuperyBlockContexts then use the old instruction pointer
to hold the compiled instruction pointer.
2) Do the argument check in compiled code as the compiler knows
how many arguments there should be. The problem here is the
compiled code would need to do a message send which means adding
a selector to the special objects array.
Either is possible. It's just a choice of costs and benefits.
At the moment, I'm favouring rejigging compiled contexts so that
compiled methods are closer to compiled blocks.
Compiled methods are the way they are because it made it easier
to bootstrap running compiled code. There's a spare slot in an
interpreted MethodContext that's used to hold the native instruction
pointer. This way if Exupery is removed a natively compiled
MethodContext can be executed by a non Exupery VM.
I'm thinking about moving the compiled instruction pointer to
the normal instruction pointer slot for both compiled blocks and
compiled methods.
For now, I'll probably stick with using the same method context class
for both natively compiled MethodContext's and interpreted
MethodContexts. This means that natively compiled methods can continue
to share the interpreters context recycling code.
Full method inlining will require inlined methods to use a separate
class so they can behave differently in the debugger. They need to
behave differently to hide being inlined.
Bryce
