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
