On the 0x41A day of Apache Harmony Alexei Fedotov wrote: > 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.
in case of bytecode ASN.1 structures will be linear cequences. No tricky nested structures like those ASN.1 is good to parse. I see no point in ASN.1 here. But you still have a chance to onvince me otherwise :) > Thanks! > > On 02 Apr 2008 11:52:25 +0400, Egor Pasko <[EMAIL PROTECTED]> wrote: > > > > On the 0x41A day of Apache Harmony Okonechnikov Konstantin wrote: > > > On 4/2/08, Alexei Fedotov <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > > > 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 > -- Egor Pasko
