Front page | perl.perl5.porters |
Postings from June 2011
2011/6/13 Nicholas Clark <nick@ccl4.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. Thanks for clarification. I slept and over it and realized that I completely mixed it up with my own bytecode ordering policy, so that I'm independent on your opcode changes. I invented that about two years ago (in bytecode.pl) and forgot it. Sorry! Please forget my rant. Issue solved. >> >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. Yes. ithreads and multi are architectural bits in the header which cannot be mapped between at all. Versions are easier as usually the semantics do not change that much between releases. And the version changes are already handled by identical code in the compiler. > 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? -- Reini Urban http://phpwiki.org/ http://murbreak.at/Thread Previous