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