[CVS ci] PMC constants and more

0 views

Skip to first unread message

Leopold Toetsch

unread,

Mar 27, 2005, 8:13:28 AM3/27/05

to Perl 6 Internals

1) the PASM and PIR assemblers are now extended to understand arbitrary
PMC constants:

.const .Integer P0 = "42" # PASM
.const .Integer i = "42" # PIR
.const Integer i = "42" # PIR

Caveat: don't use this yet, the PMC constants vanish after the first GC
sweep. See below.

The constant has to be a double-quoted string. E.g.

.const FixedIntegerArray a = "[2,3,4]"

A PMC class that supports this feature has to implement:

- freeze/thaw for getting the value to/from bytecode
- the instantiate constructor, which is called with one STRING argument
in S5 aka REG_STR(5) (see integer.pmc). It has to parse the string and
create an appropriate PMC.

We already had this construct for subroutines:

.const .Sub f = "foo"

which is actually:

set_p_pc f, pmc_constant_of_sub_foo

2) as PMC constants should work from .PBC files too, PMC constants
including subroutine PMCs are now serialized using the freeze/thaw
mechanism.

3) TODO items:

I really want to have these constants live in the constant PMC pool. The
constructor would then be a new VTABLE C<instantiate_constant> or some
such. For now they are plain PMCs, but *not* marked during DOD, so don't
use it for now. As a short-term solution we could of course scan the
constant table and mark PMC items.

This also implies that attaching non-constant items to constant PMCs is
illegal, e.g. setting properties on Sub PMCs. If you want to do this the
PMC constant has to be cloned first.

Second: to protect these PMCs from any modification, a VTABLE variant
should be swapped in that has all VTABLE slots that modify the PMC
redirected to an error function:

"Modification of a read-only value attempted at ..."

There is an experimental feature for such a scheme in the SArray PMC:

pmclass SArray const_too ...
^^^^^^^^^

This creates a second PMC class ConstSArray with a distinct type enum.
But that's basically a bad hack, e.g. the type list in classes/pmc.num
must contain an entry for that class too.

I'm not quite sure, if such read-only PMC variants should have a
separate class type enum or just a different vtable.

We need this anyway for perl6:

sub foo($a is ro, ...)

The PMC compiler already has a list of methods that modify the PMC, we
just need a scheme to create these vtable variants in a more general way.