While trying to speed up hash lookups [1] I came (again) to the problem that we are missing true PMC constants. We just have a special Sub PMC for storing subroutine entries but no general way to represent a constant PMC item. E.g.:
.const pmc s = "value" .const pmc i = 1 ... add $P0, i setprop $P0, "xxx", s
This would AFAIK not need a lot more opcode variants, because where we now have C<add_p_ic> and C<add_p_nc>, we would then just have C<add_p_pc>[2]. Only some ops that take PMCs only would need additional variants like setprop_p_sc?_pc.
I'm currently thinking of constant scalar PMCs only, but this could get generalized to constant aggregates too.
I'm all for constant PMCs--they've been in the base design since the beginning, and I'd love to get them in and running.
The interpreter stuff's simple enough--we teach the ops preprocessor to handle them the same way that it does string constants, and index into the PMC constant table. We'll want to put them in a separate part of the bytecode file, so we probably ought to nail down metadata so we can fully expose bytecode files to running code. And we need to finish that fight over freeze/thaw methodologies, as constant PMCs would end up being frozen in the bytecode.
As for the actual declaration of the constants... That's going to be somewhat interesting. I can see one of two ways of doing it:
1) we execute the initialization code at compiletime and freeze the result
2) We compile the initialization code and execute it at runtime to create the PMC
Both have their drawbacks when it comes to more complex PMCs. For simple stuff it's not a big deal one way or the other, and for the base PMC types we can even cheat and teach imcc how to create the freeze format directly, but that's not tenable as a full solution.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
