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.173 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=EFfzf+Cg3pBEZmqeTzEE1D+cd+gaD6KwBrOGdM2eHuelVPvL9gSVUxyR3rUeVxhs3kk0IX46T8lTyqUMw7f7ipo5SA+4hVKIMfq+N9xtt5SsOEkY1/og+d9zytR11Aq2qkp6V04qGAWpJt8WaXVNyhGeh+gGEGEbruJPZLz/nk0=
Message-ID: <c30d70960804020139w5664078cxd46ce86c3b606255@mail.gmail.com>
Date: Wed, 2 Apr 2008 12:39:08 +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: <0vq3aq4els6.fsf@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>
	 <0vq4panf42u.fsf@gmail.com>
	 <884d1faa0803310936i5703e01ck71798eff11a88993@mail.gmail.com>
	 <0vqmyoeeca5.fsf@gmail.com>
	 <884d1faa0804010847m1b0ad0a9v3b58360cf6037d90@mail.gmail.com>
	 <0vq8wzxdyy9.fsf@gmail.com>
	 <c30d70960804011602k5f988fb2sd0f25daea26e67e4@mail.gmail.com>
	 <c30d70960804011613j189db3c2o4d22613e326a4d0c@mail.gmail.com>
	 <884d1faa0804020037n8971e48j74ef8b882f2bbfff@mail.gmail.com>
	 <0vq3aq4els6.fsf@gmail.com>

Egor, Kostya,

Let me make my point a bit more precise: I'm afraid that the abstract
grammar is the only thing we may reuse among components efficiently.
So, reusability and generators are not two different tasks: generator
is a possible approach to reusability.

>From a technical point of view ASN.1 is used for parsing a binary
stream in runtime. It is quite efficient to populate C structures with
data.

Thanks!

On 02 Apr 2008 11:52:25 +0400, Egor Pasko <egor.pasko@gmail.com> wrote:
>
> On the 0x41A day of Apache Harmony Okonechnikov Konstantin wrote:
>  > On 4/2/08, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
>  > >
>  > > 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?
>  > > >
>  > >
>  > > Hi, Alexei!
>  > I like this approach with "first steps".
>  > Actually I have already started with IRBuilder refactoring and completely
>  > removed Simplifier from the code, tested on HelloWorld. (maybe I
>  > should try more complicated tests) Now
>  > I work on  removing SCE now. Then there will be the first patch.
>  > But it suprises me that IRBuilder should be completely rewritten!
>
>  I did not see anybody say so. I do not think that IRBuilder should be
>  rewritten. As you figured out, removing CSE and Simplifier from
>  IRBuilder makes IRBuilder better. So, let's do just that.
>
>
>  > I thought the problem was only with translator... I suppose when I am
>  > finished with IRBuilder refactoring, to start prepass and data analisys (as
>  > Egor advised), so on... and later to use IRBuilder in new translator.
>
>  sounds like a plan :)
>
>
>  > P.S. About verifier and parser generators: I will ivestigate this
>  > problem carefully.
>
>  My opinion on parser generators: Java bytecode structure was
>  specifically designed for the ease and speed of parsing. Parser
>  generators are usually used to parse tricker and much tricker
>  grammars. Sounds like an overkill to use them.
>
>  --
>  Egor Pasko
>
>


-- 
With best regards,
Alexei