harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Okonechnikov Konstantin" <okko73...@gmail.com>
Subject Re: [general] GSoC 2008 Refactor Java Bytecode Translator
Date Wed, 02 Apr 2008 07:37:36 GMT
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 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.
P.S. About verifier and parser generators: I will ivestigate this
problem carefully.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message