> I was actually thinking about this the other day so I'll chime in. I think > the reason SLICC is being run is that you need to see what files it's going > to produce to set up dependencies, basically like you might have to do if > the ISA parser split up its output files. It might be possible to cache a > list of some sort that said what all the input files were last time and > check those for changes. If you know what all the input files were last time > and none of them changed, presumably the set of input files would end up > being the same and so would all the outputs. If any input file changed all > bets would be off. I'm not sure how you'd accomplish that in scons, but it > might cut out a lot of unnecessary SLICC runs.
SLICC is being run twice, but in different modes. In the first run, SLICC parses the input files and simply returns a list of files that SLICC will generate. It does none of the actual generation. In the second mode, it actually generates the files. In effect the first case is simply replacing the scanner. The reason for this is because it's not at all obvious which files are going to be generated given a particular protocol. Nate _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
