Parrot r27355 was fun to write.
One of the persistent error messages Parrot emits for compiler writers is
Null PMC access in invoke(). If you've had your hands deep in the
guts of Parrot, you know what that means -- you tried to call a Sub PMC when
you don't have a Sub PMC, you have no PMC. (If you don't know what that means,
this entry is for you.)
Sometimes this means that there's a problem in Parrot. We've fixed almost all of those problems though, so the error usually comes from elsewhere. If you're writing a compiler, or running a compiler built on Parrot, the error usually means "You tried to call a function that doesn't exist."
Parrot's optimizer does something interesting at the end of compilation time. You've probably heard that Parrot's compiler, IMCC, translates PIR into PBC. That is, it turns source code into bytecode, which Parrot can either serialize t to disk or execute immediately. That bytecode is just a chunk of linear data in memory. It's not really a data structure. (Okay, it's a C array, but that doesn't make it a data structure.)
After IMCC has finished building a standalone chunk of bytecode, it performs a constant fixup phase. The notable part of this phase is that it edits the bytecode in place to replace all named invocations of functions known at fixup time with offset invocations.
The previous code looks something like:
invoke known_function null # padding null # padding
If IMCC has already seen known_function by this time, the
direct invocation of known_function can continue. There's no
runtime lookup necessary; all functions already compiled and ready are
available in the bytecode.
If IMCC hasn't seen that function, runtime lookup is necessary, and so this function replaces the bytecode earlier with the equivalent of:
.local pmc func func = find_name 'unknown_function' invoke func
(I've simplified what actually happens slightly, because the concepts are more important than the details. Hopefully you see why the padding is necessary. If not, just imagine trying to splice additional opcodes into what may presumably be a lengthy C array -- like I said, barely a data structure.)
The problem with this second form occurs when find_name returns
a NULL PMC, which it can legitimately do. In that case, the
invoke opcode tries to invoke a NULL PMC and fails, and Parrot
throws an exception saying "There's nothing here to invoke." There's the error
message.
It's clear why that happens, but it's not useful. It would be more
useful to see the name of the function you tried to invoke in the
error message. Unfortunately, by the time Parrot calls the invoke
op, that name is long gone.
My first idea was to rewrite the dynamic lookup form into something resembling:
.local pmc func func = find_name 'unknown_function' if defined func goto call_it die "Can't invoke 'unknown_function'" call_it: invoke func
Unfortunately, I didn't have the space in the bytecode stream to insert that many ops, and I had no desire to move chunks of memory around in that C array. I could have added more padding after an invocation, but to be fair I'm only mostly sure that it exists there in the first place.
I had room for one op with a destination PMC and a string constant argument.
I added an experimental op called find_sub_not_null which does the
same thing as find_name but throws an exception which includes
the requested name if Parrot can't find a PMC of that name.
This isn't entirely an ideal situation. It's a special case op, and I prefer to remove ops where possible. It's also nearly code duplication, though it's effectively three lines of code in an op, which isn't awful. I still want to be able to perform these kinds of transformations in PBC itself, but we need a different way to generate PBC and perform op-level transformations in PIR before we can do this effectively.
There are always tradeoffs, though. Doing this check in C is slightly faster than doing it in PIR. The standard Perl 5 rule of optimization applies even in Parrot -- the fewer ops, the mostly faster you can go. As well, I was able to improve the warning message today, rather than at some point in the future when we have better PBC optimization possibilities.
After all, I can always remove this op in the future.
