harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [general] GSoC 2008 Refactor Java Bytecode Translator
Date Wed, 02 Apr 2008 07:52:25 GMT
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


Mime
View raw message