So I'm getting a little confused... sorry but I've been traveling this week and haven't had a lot of time for email. It seems like the other patch was all about adding support in CPU models for predication, and now we're talking about adding support in the parser... from 10,000 feet I almost feel like people are arguing flipping sides in the debate between these two threads. (Though maybe Gabe is being consistent in that he wants *all* the complexity in the ISA description?)
>>>> The isa parser already generates 130,000 lines of code per cpu model and >>>> 75,000 lines of decode. It takes over 1GB of memory and 4 minutes to >>>> compile a CPU model. The compile time is irrelevant... it's only because we haven't gotten around to adding the features that allow you to split the output code into multiple files. >>>> It seems like the >>>> right answer in this case is to have the isa parser be able to figure out >>>> what registers need updating when an instruction is predicated false and do >>>> the update. My confusion is why we need the ISA parser to do that... why can't you just look at the destRegs field of the staticInst to figure this out? >> I understand that you don't want to make the parser more complex and I >> understand the reasons why. My point is that some complexity in the parser >> is much better than 10x the complexity somewhere else. If you look at what >> is changed in the parser, for the case without reset_code substitution, it >> changes very little. The bulk of the changes are the makeReset() blobs, >> which are pretty-much boiler plate. In my mind, this is the least bug-laden >> approach and any other ISAs with predication can take advantage of the same >> mechanism to implement it. I'm not necessarily opposed to putting it in the parser if that is the best place, I just don't understand why it's so hard to do in the O3 model. The thing I like about doing it in O3 is that we localize the support for renaming to the model that actually does renaming, and we leave the door open for people who have brilliant new ideas about how to handle renamed predicated instructions to do it differently. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
