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 ClarkThread Previous | Thread Next