2011/6/13 Nicholas Clark <nick@ccl4.org>: > On Mon, Jun 13, 2011 at 06:58:34PM +0200, Reini Urban wrote: >> Sigh, >> bfa148846 Reorder ops so that trans{,r} and aelemfast{,_lex} are adjacent >> >> This reshuffles for no apparent win all op numbers > 35, and thus >> makes it very hard >> to maintain .pmc bytecode compatibility. >> New ops should go to the end. > > This isn't a change that gets into a maint branch. Why? You just broke it so I request it to be reverted. > You have bytecode compatibility between different major versions of Perl 5? > > How does that work, given that this is between versions that can well have > different SV flags (if not different meanings for the SV types), can have > different op flags (or different meaning for the op flags), and different ops > available. This worked fine from 5.005 to 5.14 on (with a small hole at 5.10), and I don't understand why I shouldn't continue to work for 5.16 onwards. You are trying to change an unwritten policy which lasted from 1997 on at least. Changed internals flags are of course a semantical problem, but rarely cause real problems. In this case re-compilation is needed. 5.8 <-> 5.10 flags and semantics were a problem, but the rest not. A semantical translator to adjust features for some ops is MUCH easier than a translator which must re-arrange all ops. And it completely voids the bytecode table as it now is maintained. >> I know this is Nick and he will not care at all but can someone else >> support my argument? > > Phrasing it like that is likely to *reduce* your chances of getting anyone > to do what you request. Why? So far only Nick broke my stuff and blocked my fixes. This time again. He obviously has no idea of my work. Someone really have to stop this somewhen, or B::Generate and its underlying compile-time optimizations and the compiler with its company usage behind will not be maintainable anymore. Which is a shame because a lot can be improved. This problem has to be resolved. -- Reini UrbanThread Previous | Thread Next