> To answer Nate's question, it is the later reason. Because SLICC generates > different classes with the same name depending on the protocol, I don't think > it is possible to former.
The difficulty with the former is not the filenames, but symbols. It would be easy enough to do src/mem/protocol/MI_example and src/mem/protocol/MESI_CMP_directory and pick which set of autogenerated files to link into the binary based on the PROTOCOL variable. The question that I don't know is if SCons will force a recompile of those files anyway when you switch PROTOCOL. We could try. This would not give you two different m5.opt binaries when you compile, but would potentially save time when you switched between them by not recompiling stuff. > Could we generate all protocol files outside of the build directory and > then tell scons to copy only the necessary protocols files to the > appropriate build directory? I don't think so. Scons tends to be smart about things and it gets in your way when you try to play tricks. Right now, we do have a similar problem when we build say both ALPHA_SE and ALPHA_FS, but what actually happens under the covers is that every file that is shared between the two (without any differing #defines) is still compiled twice. I'm nearly done with a big change to SCons that fixes this problem. I can work the protocol into this framework as well. The real solution in the long run is to allow multiple protocols to be compiled into a single M5 binary. This isn't hugely difficult, but would require some work because as things stand now, there will be symbol conflicts. The solution is to make generated code and code that uses generated code take the PROTOCOL as a template parameter. I'll have to look through ruby/slicc to see how much work this will be. > - SLICC generation parsing error support in scons > > Of the four issues I listed, this is definitely the lowest priority, so I'm > happy to > put it on the back burner. I just wanted to point out right now the > ParseError > just provides a file name and the LexToken that describes the error. If you > know that the third parameter of the LexToken is the line number, then that > is all the information an experience SLICC programmer needs to debug. > However, I'm concerned for novice SLICC programmers who may need > more information. This has to do with the fact that there are actually two slicc parsers. One written in python used by SCons, and a second which is the actual slicc parser. I created the first because SCons needs to know the names of the files that slicc will generate and I couldn't actually get that information without running slicc. I tried to hack it in, but in the end, it was just easier to do what I did. Generally, syntax errors are the only thing that should give you these sorts of error messages and I can improve them. If there are worse errors, slicc itself will run and give you the more detailed error message. Is this situation really bad? Does SLICC give better messages (other than just reformatting them to include the line and column number) on syntax errors? I was intending to go back and look at slicc itself and see if I could modularize it a bit better to do what the python code does. I could also see what I can do about generating code that uses templates. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
