Ticket #451 (closed experimental: invalid)

Opened 6 years ago

Last modified 4 years ago

Anticipated changes to bytecode

Reported by: allison Owned by:
Priority: normal Milestone: 3.0
Component: core Version:
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:

Description (last modified by coke) (diff)

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.

Change History

follow-ups: ↓ 2 ↓ 5   Changed 6 years ago by 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

in reply to: ↑ 1   Changed 6 years ago by 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.

  Changed 5 years ago by coke

  • summary changed from [CAGE] Anticipated changes to bytecode between 1.0 and 1.4 to [CAGE] Anticipated changes to bytecode before 2.0
  • description modified (diff)
  • milestone changed from 1.4 to 2.0

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.

  Changed 5 years ago by coke

  • summary changed from [CAGE] Anticipated changes to bytecode before 2.0 to Anticipated changes to bytecode before 2.0

in reply to: ↑ 1 ; follow-up: ↓ 9   Changed 5 years ago by 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.

  Changed 5 years ago by chromatic

  • status changed from new to closed
  • resolution set to invalid

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

  Changed 5 years ago by coke

  • status changed from closed to reopened
  • type changed from cage to experimental
  • resolution invalid deleted

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.

  Changed 5 years ago by 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.

in reply to: ↑ 5   Changed 5 years ago by 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

  Changed 4 years ago by coke

  • summary changed from Anticipated changes to bytecode before 2.0 to Anticipated changes to bytecode
  • description modified (diff)
  • milestone changed from 2.0 to 3.0

push this out to 3.0

  Changed 4 years ago by jkeenan

  • component changed from none to core

  Changed 4 years ago by jkeenan

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

Thank you very much.

kid51

  Changed 4 years ago by 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

  Changed 4 years ago by cotto

  • status changed from reopened to closed
  • resolution set to invalid

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.

Note: See TracTickets for help on using tickets.