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: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] 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 m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
