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
