petdance/scratch — Issue #896: [RFC] Merge freeze/thaw with PBC
Author: petdance
Created: 2011-11-01 05:37:17+00:00
State: open
Labels: core, Pri-normal, rfc, Sev-medium

= Problems =

freeze/thaw and PBC are already inter-related:
* PBC uses freeze/thaw for constants
* freeze/thaw uses PBC's low level binary IO abstraction

freeze/thaw currently has issues related to subs. Specifically, the opcodes for the sub aren't frozen with the sub. The reason for this is that, when a sub is a constant in a PBC, the opcodes are stored elsewhere and the sub should be an index into the code segment.

Also, PBCs as they currently exist are more or less equivalent to frozen Eval PMCs (in function, not format).

The bottom line is we have 2 formats that are inter-dependant and have overlapping functionality.

= Proposed Solution =

Have freeze/thaw operate on a slight variant of PBC. That is, freeze returns a string containing the contents of a PBC file, and thaw would operate on such strings.

= Required Modifications to PBC =

Minimal. A new segment would need to be added for non-constant objects. For backwards compatibility, we could make the absence of this segment default to creating an Eval PMC.

= Required Modifications to freeze/thaw =

The IMAGE_IO object (or whatever we replace it with) would need to gain the concept of bytecode management. Sub PMCs would be responsible for adding their bytecode to the image on freeze and obtaining their bytecode on thaw. Eval PMCs would no longer manage the bytecode for all contained subs for freeze/thaw as these are now responsible for handling that themselves.

= Benefits =

* Elimination of duplicated functionality.
* Sub PMCs frozen/thawed sanely.
* PBC becomes more flexible from PIR/HLL perspective:
* compilation: just freeze an Eval PMC.
* examination: thaw to Eval PMC and poke it
* load_bytecode is something like:
{{{
.sub 'load_bytecode'
.param string filename
$S0 = slurp_file(filename)
$P0 = thaw $S0
$P0()
.end
}}}
Trac ID #1359