develooper Front page | perl.perl5.porters | Postings from June 2011

Re: bfa148846 Reorder ops so that trans{,r} and aelemfast{,_lex} areadjacent

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
June 13, 2011 14:01
Subject:
Re: bfa148846 Reorder ops so that trans{,r} and aelemfast{,_lex} areadjacent
Message ID:
20110613210133.GA23881@plum.flirble.org
On Mon, Jun 13, 2011 at 09:34:04PM +0100, Zefram wrote:
> Reini Urban wrote:
> >2011/6/13 Nicholas Clark <nick@ccl4.org>:
> >> This isn't a change that gets into a maint branch.
> >
> >Why? You just broke it so I request it to be reverted.
> 
> We maintain binary compatibility along each maint branch.  Op renumbering
> would be a major binary incompatibility.
> 
> We do not attempt to maintain binary compatibility between major
> versions, and indeed in practice there are always significant binary
> incompatibilities.  It may not have been op renumbering before, but
> that's by chance, not by policy.

We renumbered ops before in 2e0eeeaafce11cb0, 996c9baa63e0776f,
e71197e288306365, 5edb5b2abb5db9e1, 878d132a73f5d089, fdecdb95df591262,
5b9081af6a5719eb, 7834bb7eff465724. (The first four in that list were between
5.10 and 5.12)

This isn't new.

> >A semantical translator to adjust features for some ops is MUCH easier than
> >a translator which must re-arrange all ops.
> 
> You'll find a much higher degree of compatibility between major versions
> in the op *names*.  It should be easy to perform the translation you
> need by using the names as version-independent op type identifiers.
> Likewise for flags, when they move.

We've also changed the mapping of SV type numbers to SVs each time between
5.8.0, 5.10.0 and 5.12.0, and eliminated various existing SV types.

If I'm following the code of B-C correctly, the architecture of the bytecode
hasn't changed since maint-5.8, and it still writes U32s direct to SV flags,
and U8s direct to op_flags and op_private. Hence, any change to the binary
values of symbolic constants for any of these fields (and probably others)
would need to be remapped to load older bytecode. Remapping op numbers is
trivial compared to that. And even that *still* won't allow interchange
between threaded and unthreaded perls.

It's a lot of work - what's the gain over simply taking the perl sourcecode
in question and regenerating bytecode on a newer version?

Nicholas Clark

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About