Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of alexei.fedotov@gmail.com
 designates 66.249.92.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=oXNRZb4HU2eOdrYLGwn2lOTiua9NB0JpyTZ7m9MmDMg3nYJPmKUosrtjQQRL2m2itNq+zVZEJNw6jr62gjvFimG9jVNwF5hYIKPSJA/ndlAtXf/c2FBlK46qrrIKAjz8UOX8jG0y4fkIGFrX494fkAO56xBDwyMsKFkNBlrE2Nk=
Message-ID: <c30d70960804011613j189db3c2o4d22613e326a4d0c@mail.gmail.com>
Date: Wed, 2 Apr 2008 03:13:15 +0400
From: "Alexei Fedotov" <alexei.fedotov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [general] GSoC 2008 Refactor Java Bytecode Translator
In-Reply-To: <c30d70960804011602k5f988fb2sd0f25daea26e67e4@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <884d1faa0803192322o7b9f58dfja181970fbe2f882e@mail.gmail.com>
	 <0vqabkhhgrh.fsf@gmail.com>
	 <884d1faa0803300533h181c323cv4a8d5ee9875ff059@mail.gmail.com>
	 <884d1faa0803301138v1e84b867wfcc907cf86ccd20c@mail.gmail.com>
	 <0vq4panf42u.fsf@gmail.com>
	 <884d1faa0803310936i5703e01ck71798eff11a88993@mail.gmail.com>
	 <0vqmyoeeca5.fsf@gmail.com>
	 <884d1faa0804010847m1b0ad0a9v3b58360cf6037d90@mail.gmail.com>
	 <0vq8wzxdyy9.fsf@gmail.com>
	 <c30d70960804011602k5f988fb2sd0f25daea26e67e4@mail.gmail.com>

One more idea on further rewriting.
1. An old verifier built some IR on the top of bytecode.
2. A new verifier also does parsing, but is more like JET.

You may think of building a reusable component. I wonder if
conventional parser generators or ASN.1 are applicable here. Note,
thinking is different from starting doing, there are cases when a
specific solution is better than reusable.


On Wed, Apr 2, 2008 at 3:02 AM, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> Hello, Kostya,
>
>  Do you think it would be good to reflect Egor's (and mine) idea of an
>  evolutionary path during learning period during the first step of your
>  plan? Namely, incremental approach to IR separation are subsequent
>  patches to the existing code base. Each of the patches does the
>  following:
>  1. Removes some optimization from the parsing stage.
>  2. Adds necessary infrastructure to HIR.
>  3. Adds or ensures that the optimization is done on HIR.
>
>  This would help attacking the problem and learning a parser, HIR and
>  tools incrementally. On completion of this step you would have your
>  code committed to Harmony and get more confidence. Moreover the code
>  which enhances HIR would be close to final. In process you will learn
>  why the existing IR builder is bad and grow a desire to attack it
>  fully rewriting the code.
>
>  What do you think?
>
>
>
>
>  On 02 Apr 2008 01:53:18 +0400, Egor Pasko <egor.pasko@gmail.com> wrote:
>  > On the 0x419 day of Apache Harmony Okonechnikov Konstantin wrote:
>  >  > > Let's not remove copy propagation, it does not make the code
>  >  > > difficult, does not add lots of lines, but still very functional.
>  >  > >
>  >  > > OK?
>  >  > >
>  >  > > --
>  >  > >
>  >  > > Egor Pasko
>  >  > >
>  >  > >
>  >  > OK, got it.
>  >  > What are the requirments for simplify and hvn passes?
>  >
>  >  what do you mean by requirements? they should optimize the code, that
>  >  is one requirement, but if they make things slower in some cases, that
>  >  happens too :)
>  >
>  >
>  >  > Currently I am testing using this optimizer
>  >  > chain: ssa,devirt,inline,purge,simplify,dce,uce... (didn't include hvn yet)
>  >
>  >  we can check later whether we need hvn here or not
>  >
>  >
>  >  > BTW, I' ve updated my application and put it on the wiki
>  >  > http://wiki.apache.org/general/WikiTranslatorRefactoringProposal.<http://wiki.apache.org/general/WikiTranslatorRefactoringProposal>
>  >
>  >  doing good, probably somebody can give more valuable comments now.
>  >
>  >  --
>  >  Egor Pasko
>  >
>  >
>
>
>
>  --
>  With best regards,
>  Alexei
>


-- 
With best regards,
Alexei