> Are you sure? Running SLICC every time just to get a (typically unchanging) > list of files is not exactly instantaneous, and the names of the SLICC > output files hardly ever change. What about this approach: It is pretty fast (and this includes starting the python interpreter) 0.48s user 0.03s system 99% cpu 0.514 total
> 1. store the list of output files > 2. scons builds a dependence graph based on that stored list > 3. when the SLICC files change and actually need to be re-parsed, we compare > the output file list generated as a side effect with the stored list > 4. if those lists differ, scons blows itself away and starts over > 5. if not, we can get by without parsing the SLICC files at all in the > common case where you're rebuilding the binary and none of the SLICC inputs > have changed > > Yes, step 4 is ugly and expensive, but the key is that it should hardly ever > happen. "Make the common case fast", and all that. If we commit the output > file lists to hg, it wouldn't even need to happen on a clean build. > > Just brainstorming... I think you're pre-optimizing. How long does the ISA parser actually take to parse the files? Nate _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
