Just an FYI, I'm currently making changes to both the parser and code generator. I should be able to push those today if you want to hold off on the conversion.
-Derek On Tue, Aug 4, 2009 at 9:58 AM, Beckmann, Brad<[email protected]> wrote: > Great. Being able to diff the two sets a files will certainly ease debug. > > I hope you don't mind me asking, but why does the fragility of generated code > matter? One should never modify generated code and only rarely look at it. > > I'm interested to hear your ideas about how moving SLICC to python helps > unify the GEMS and M5 configuration. As we all know this is a pretty > significant challenge that will be solved in multiple steps. I just want to > make sure we are all on the same path. > > Brad > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > nathan binkert > Sent: Monday, August 03, 2009 9:46 PM > To: M5 Developer List > Subject: Re: [m5-dev] Python SLICC > > The initial step is to simply translate the C++ code to python. I > plan to change nothing about the AST structure or anything like that. > The end result should be files that can be diffed, though will likely > need to be diffed ignoring all whitespace. > > Once this is shown to work, then we can look at cleaning stuff up. > One of the major reasons to do this is that the generated code is so > fragile. Also, having translated a fair chunk of the generated code, > it would be nice if the code generator were more modular. I think > this would be a lot easier to do in python. > > Nate > >> As someone who is very familiar with how SLICC currently generates code, >> I'm little concerned about changing the core of GEMS but maybe I just >> need to understand what you are proposing in more detail. Sometimes >> SLICC generation bugs can be hard bugs to find and I would be leery of >> potentially break it. It might be a lot of work to debug. >> >> I would like to know more details about what you are proposing. Would >> SLICC maintain the same formatting rules and AST structure? Therefore, >> the only changes beyond the new parser are the ast and symbol files >> would be implemented in python instead of C++, right? If that is the >> case, then you can verify Python SLICC by simply diffing the new >> generated files with the old generated files. That would be nice test >> to use, especially if you could test it across a few different >> protocols. >> >> If Python SLICC allows us to get closer to a unified configuration >> system, then that is a major plus. I would like to know more details of >> exactly what path you are thinking of and how Python SLICC helps. >> >> Thanks, >> >> Brad >> >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On >> Behalf Of nathan binkert >> Sent: Monday, August 03, 2009 8:29 PM >> To: M5 Developer List >> Subject: [m5-dev] Python SLICC >> >> So, maybe I'm crazy, but a whole bunch of things got me convinced to >> started converting SLICC to python. Before I go way too far, I want >> to see if any of the Wisc have any objections to this. >> >> Here are what I see as the benefits: >> >> 1) Use python's powerful formatting function + triple quoted strings >> to make the code generator something that humans can more easily >> follow. If people want, I can send examples. >> >> 2) Make it easier to hack on the generated code. This is basically >> because #1 makes life easier. This is important for things like >> moving to M5 style configuration. >> >> 3) Reduction of total code by 50-70%. This is just a rough guess, but >> it mostly comes from #1, being able to be more concise when working >> with containers, and just plain being able to say more in each line. >> >> 4) It should be easier to improve SLICC in the future (Derek, I can >> help port SLICCer). >> >> 5) Deal with the generated files problem in a simple way. I tried to >> hack on SLICC to get it to tell me what files it would generate from a >> protocol specification. That proved difficult (I worked on it for >> several hours) because of these formatting issues and general >> difficulty with extending SLICC. The end result was that I ported the >> SLICC grammar to python (using PLY it took an hour) and wrote a quick >> script that did this job for me. By converting everything to python, >> there'd be just one grammar to worry about. >> >> 6) I can get rid of those intermediate #includes that SCons generates >> >> 7) PLY (Python Lex-Yacc) rocks and is generally easier and a whole lot >> more fun to work with than lex/yacc >> >> 8) I can learn a lot about SLICC in the process. >> >> Downsides: >> 1) This will probably use two more days of my time. I spent a few >> hours at it and probably converted about 25% of the code already. >> 2) I could introduce new bugs. >> 3) Maybe my changes will be superseded by SLICCer. >> >> Nate >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> >> >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> >> > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
