I had similar thoughts... I think Gabe's idea could work, but I'm not sold on the motivation. If it's just for performance, do we know for sure that this is actually a performance bottleneck?
Also, I don't think we can get rid of the MiscReg space and the indices, since they're needed to indicate dependencies (though I think most if not all MiscReg dependencies are handled through other means, such as marking the instructions that write them as serializing). If bypassing the indices for accesses meant we could get rid of the indices altogether then I'd feel more favorable since the net amount/complexity of code might be the same or reduced. However if we can't get rid of the indices then having a different access method that doesn't use them seems like additional complexity, which is generally best avoided unless it's really necessary. What do you think, Gabe? Steve On Tue, Sep 8, 2009 at 7:42 PM, nathan binkert<[email protected]> wrote: > How often are these functions used? I'd have thought that they're not > so frequent and wouldn't warrant optimization. Also, couldn't they > just be inlined? Or is the variable obfuscated in such a way that the > compiler doesn't know what it is at compile time? > > Nate > >> Hello everybody. I was thinking the other day that it might be a good >> idea to templatize readMiscReg and setMiscReg. I don't have the idea >> fleshed out all the way, but I thought it would be a good idea to send >> an email to before I forgot about it. >> >> When we access control registers, my impression is that we almost >> always know which one we want. There are some exceptions where things >> are accessed in a loop, but usually there's a specific place where we >> need a specific register for a specific purpose. What happens, though, >> is that we call a function that handles -all- registers, and it has to >> switch on a parameter to redetermine what we wanted to do. If we >> called a specific function for, say, reading CR0, we'd skip the >> overhead of the switch statement. We'd also make the functions that >> set/read those registers shorter and more managable. >> >> In x86, I use bitunion types to split out the bitfields of a register. >> Because of that, basically each of the control registers already has a >> type that corresponds to it specifically. There are some exceptions >> where the same type is used for more than one register, but I don't >> think that's the common case. That type could be used as the template >> parameter to the read/set functions which would cause template >> instantiations all the way back into the isa object. >> >> Once there, template specialization would let you define a function >> that reads/sets just CR0, and the type system and C++ would plop it >> into place at the right place and time while still respecting >> interfaces. It might even be inlinable. The regular version that takes >> an index would still be available. I'm not quite sure how to fold it >> into the templated version of that function since the index is >> explicit, but since it's likely going to be (and probably should >> normally be) a MiscReg, that might work out. >> >> Gabe >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> >> > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
