PMC constants
Leopold Toetsch
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.
Comments?
leo
[1] constant _S("string") gets a precomputed hash value
[2] Compiling "add P0, 1" imcc would look for add_p_ic and if this isn't
there then for add_p_pc *and* convert the constant.
Dan Sugalski
>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
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> 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,
Why I second table? This just adds duplicate code paths and complexity.
One constant table ought to be enough.
> 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.
The freeze/thaw internals can change. We only have to invalidate
existing PBCs, if the frozen image format differs.
> 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
It probably depends on the PMC. *If* there are any side effects,
initialization has to be done at run time.
leo
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> wrote:
>
>> 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,
>
>Why I second table? This just adds duplicate code paths and complexity.
>One constant table ought to be enough.
Mainly because I was assuming that we were going to separate the
float, pmc, and string constants into separate tables for
locality-of-reference reasons and ease of doing reflective access.
(Or something line that...)
> > 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.
>
>The freeze/thaw internals can change. We only have to invalidate
>existing PBCs, if the frozen image format differs.
Yep. I thought there was still some outstanding stuff, but it might
just be dodgy memory on my part.
> > 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
>
>It probably depends on the PMC. *If* there are any side effects,
>initialization has to be done at run time.
Yeah, but we have to pick one. :(
Leopold Toetsch
> At 8:30 AM +0200 4/20/04, Leopold Toetsch wrote:
>>
>>Why I second table? This just adds duplicate code paths and complexity.
>>One constant table ought to be enough.
> Mainly because I was assuming that we were going to separate the
> float, pmc, and string constants into separate tables for
> locality-of-reference reasons and ease of doing reflective access.
The constants are currrently a typed union, so there is some wasted
space. OTOH constants compiled at the same time tend to stick together
(modulo constant folding of course). Three distinct tables could have
worse locality then one. Dunno.
>>The freeze/thaw internals can change. We only have to invalidate
>>existing PBCs, if the frozen image format differs.
> Yep. I thought there was still some outstanding stuff, but it might
> just be dodgy memory on my part.
$ parrot parrot-config.imc VERSION
0.1.0
is accessing the frozen image of the config hash. Most of the basic
types are working.
>> > 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
>>
>>It probably depends on the PMC. *If* there are any side effects,
>>initialization has to be done at run time.
> Yeah, but we have to pick one. :(
For
.const PerlInt i = 5
or some such, the compiler knows the type and can freeze the compiled
result. It's of course the question, what is all allowed to create a
PMC constant.
leo