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

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

Thread Previous | Thread Next
From:
Reini Urban
Date:
June 13, 2011 13:22
Subject:
Re: bfa148846 Reorder ops so that trans{,r} and aelemfast{,_lex} are adjacent
Message ID:
BANLkTimZMkUwi6P3XHBj5=_NBfjELrKnTg@mail.gmail.com
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 Urban

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