Anticipated changes to bytecode

[allison]

We anticipate making changes to the bytecode format; These changes are likely to include: changes to the bytecode file structure, changes to opcode numbering, and changes to PMC numbering.

[bacek]

Hello.

I have proposal to change PBC format to be platform-independent.

Current design implies that PBC opcodes (and values) can be directly evaluated from file on "native" platform. But this leads to next problems:

1. Evaluating opcodes directly is major abstraction leak between storage format and interpreter internals.

2. Requires expensive testing of about 144 permutations between different supported platforms. See #385 for example. Currently there is no automatic testing of PBC at all.

My proposal is:

1. choose one platform independent PBC format.

2. PBC testing on particular platform will implies only 2 steps:

2a. Compare result of "pbc_dump" for preconstructed PBC with canonical one.

2b. Create PBC and binary compare it with preconstructed canonical one.

(For some meanings of "pbc_dump" and "binary compare")

Simplified testing will give ability to go forward with constructing bytecode directly from POST, implement bytecode optimizers and so on.

-- Bacek

[doughera]

Replying to bacek:

I have proposal to change PBC format to be platform-independent. Current design implies that PBC opcodes (and values) can be directly evaluated from file on "native" platform. But this leads to next problems: 1. Evaluating opcodes directly is major abstraction leak between storage format and interpreter internals.

One might view this instead as a major opportunity for efficiency, I agree that this "efficiency" is an unproven hope, not a benchmarked finding, but the basis for that hope is not unreasonable.

A little more background on the idea is in this thread:  http://www.nntp.perl.org/group/perl.perl6.internals/2002/10/msg13339.html as well as in  http://www.sidhe.org/~dan/blog/archives/2005_06.html (note the entry WWIT: Fast interpretation.) There are many other references in the archives as well; this is not intended to be an exhaustive list.

[coke]

Since DEPRECATED.POD wasn't really updated to address this ticket (the notice is unchanged in the 1.4.0 release), I think we can safely say this counts as an ongoing maintenance item. Updating subject, description, milestone.

[allison]

bacek, thanks for the suggestion, but it is worth holding on to the potential optimization of platform-native bytecode.

The solution to the bytecode testing problem is to make it possible for all platforms to read and write bytecode for another platform, and to test freshly generated bytecode rather than (out-of-date) bytecode checked into the repository.

[chromatic]

2.0 is out. Anything we didn't do here needs a new ticket.

[coke]

Re-opening; this is a placeholder in DEPRECATED.pod to cover the experimental status of: packfile structure, opcode numbering, and PMC numbering.

Leaving open until we figure out how we want to Trac those experimental items.

[NotFound]

In r44253 I added the method set_main to the PackfileConstantTable PMC, in order to set the :main modifier in experiments of pbc creation. I assume his experimental status is covered by this ticket and doesn't need his own note.

[bacek]

Replying to allison:

The solution to the bytecode testing problem is to make it possible for all platforms to read and write bytecode for another platform, and to test freshly generated bytecode rather than (out-of-date) bytecode checked into the repository.

Niiice... So we are going to test all 144 permutations? And add a _lot_ of code to write "foreign-platform-native" pbc?

-- Bacek

[coke]

push this out to 3.0

[jkeenan]

Can we get an update on the status of this ticket?

Thank you very much.

kid51

[bacek]

Hello.

I would like to close this ticket. Representation of PBC is internal to parrot, not visible outside of parrot and doesn't affect our users. So we can change it at any time (as plobsing++ did) without affecting anyone. Having such broad ticket doesn't buy us anything.

-- Bacek

[cotto]

I agree with bacek here. We'll deprecate specific items as needed but PBC is an implementation detail that shouldn't be a deprecation concern.