Front page | perl.perl5.porters |
Postings from December 2010
Re: Adding codegeneration step
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
December 31, 2010 04:55
Subject:
Re: Adding codegeneration step
Message ID:
20101231125526.GJ24189@plum.flirble.org
On Fri, Dec 31, 2010 at 01:40:57PM +0100, Gerard Goossen wrote:
> On Fri, Dec 31, 2010 at 09:02:27AM +0000, Nicholas Clark wrote:
> > On Thu, Dec 30, 2010 at 11:09:27PM +0100, Gerard Goossen wrote:
> > > I will send the patches afterthis, but the changes are in the codegen
> > > branch at git://github.com/ggoossen/perl.git or to view the commits
> > > https://github.com/ggoossen/perl/commits/codegen
> >
> > I see that your final commit is:
> >
> > 98 files changed, 8360 insertions(+), 6617 deletions(-)
> >
> > Is there any way to break that down into more manageable parts?
>
> Splitting it into smaller parts is rather difficult (of course it could
> be split into changes to modules (mostly B modules) (about 2k lines),
> auto-generated files (1-2k lines), but I don't think that would make it
> more manageable).
> But I don't see how it can be split into smaller steps, you can't do
> half a code generation step.
OK. The error on 64 bit systems reveals that you've refactored
Perl_try_amagic_bin() and similar to take a 3rd parameter, targ. Previously,
I see, they used dTARGET internally. *That* is the sort of change that I
feel could and should be broken out.
> Maybe telling a little more about the changes is more useful:
> The bulk of the new code is in codegen.c, most of which is converting the
> optree into a instruction list, with a large "case" statement handling
> the different optypes. At the top of codegen.c there is some documentation
> about how this is done. Most of the removed code is in op.c where a lot of
> optree manipulation is removed, which is replaced by code in codegen.c
> Most of the other changes have to do with "return addresses" now being
> INSTRUCTION* instead of OP* and using the arguments in the pp_*
That still doesn't change the fundamental problem - you're proposing to
make a fourteen THOUSAND line change with the most minimal of commit messages.
Sure, the above is better than your original intended commit message:
commit 2eb5e64f14dad46eaf71bccff4aafe2d786d2681
Author: Gerard Goossen <gerard@ggoossen.net>
Date: Tue Nov 17 11:05:51 2009 +0100
codegeneration step
2 words!
but your plan would create a maintenance nightmare. It's impossible to bisect
problems within a single commit, a single commit which is bound to add some
bugs as well as intended changes. Hence any problems discovered after making
such a change are going to be nigh on impossible to diagnose, let alone fix,
because a single commit means that it's going to be beyond anyone's ability
to understand the logical sequence of steps that the change represents, and
hence identify flaws in them.
Nicholas Clark
Thread Previous
|
Thread Next